Skip to main content

What breaks when HubSpot company address fields don't match Salesforce?

HubSpot stores a company's address as flat properties (city, state) while Salesforce prefixes the same concept (BillingCity, BillingState). A workflow or mapping built against one and pointed at the other silently writes to nonexistent fields or leaves AR remittance addresses blank — there's no error, because both systems accept the write and simply don't have a field by that name to reject.

Zuny FesterBy Zuny Fester, Head of Operations and Marketing
Reviewed by Zuny Fester
Published Last reviewed Editorial policy

Part of the finance integrations guide.

SymptomAR remittance address is blank or stale after a CRM migration or dual-write setup
Root causeField-name mismatch: HubSpot uses flat properties, Salesforce uses Billing*-prefixed fields
Why it's silentWriting to a property name that doesn't exist on the target object doesn't error — it's simply ignored or creates an unused custom property
Where to checkCompare the exact property/field names configured in the integration mapping against each system's actual schema, not assumed names

Why this happens during migrations and dual-CRM setups

Companies migrating from Salesforce to HubSpot (or running both during a transition) often carry over an existing field mapping without re-deriving it. Salesforce's Account object prefixes billing-address fields as BillingStreet, BillingCity, BillingState, BillingPostalCode, and BillingCountry. HubSpot's Company object uses flat, unprefixed properties for the same data — address, city, state, zip, country, confirmed directly in HubSpot's own API documentation. A mapping written for Salesforce's field names, pointed at a HubSpot company object, references properties that simply don't exist there.

Why it doesn't throw an error

Both HubSpot's and Salesforce's APIs generally accept writes to custom or unrecognized property names rather than rejecting them outright — HubSpot in particular will silently create a new custom property if one doesn't exist under the name you're writing to, rather than failing the request. The practical effect: the write "succeeds," the AR system's designated address field stays empty or shows a prior value, and nothing in the integration's logs flags it as a failure.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Field mapping

Salesforce vs. HubSpot billing-address field names

ConceptSalesforce Account fieldHubSpot Company property
StreetBillingStreetaddress
CityBillingCitycity
StateBillingStatestate
Postal codeBillingPostalCodezip

Frequently Asked Questions

No — it typically creates a new custom property under that name rather than rejecting the write, which is exactly why the mismatch stays silent instead of throwing an error.

Diff the actual property/field names your integration mapping references against each system's live schema — don't assume a mapping built for one CRM transfers to another without changes.

No — it's a general risk for any field-name mapping carried over between CRMs with different naming conventions, address fields just happen to be the most common case because of the Billing* prefix pattern.

Sources

Related