Address Wrong After Sync: Why the Unit Number Vanishes

When an address comes out wrong after a sync, the cause is almost always that the two systems disagree on what an address is made of. One stores the street as a single field, the other as two or five lines; one stores the state as "Massachusetts", the other as "MA". The mismatches that throw errors, like Salesforce rejecting a state, get fixed in a day. The ones that do not, like a suite number dropped because nobody mapped line 2, sit in the CRM until a technician knocks on the wrong door. The durable fix is one canonical address shape at the boundary, with the unit as its own field and state and country stored as codes.

What is an address, to the systems in your stack?

Six parts: street, unit, city, state, postal code, country. Every system agrees on city and postal code, more or less. They disagree on how to cut the street, and on whether state and country are names or codes. As of September 2026, the vendors' own docs describe these shapes:

System	Street and unit	State	Country	Where it bites
HubSpot contact	One Street address property, defined as including the apartment or unit	State/Region (text) plus a separate two-letter State/Region Code	Country/Region plus a two-letter Country/Region Code	Receives a unit fine; loses it when a split source maps only line 1
Salesforce, picklists on	One Street text area	Text State must match an integration value (full name by default); StateCode takes the code	Same pair: Country text and CountryCode	Rejects names that do not match, and rejects a state with no country
Stripe customer	line1 and line2, where line2 is apartment, suite, unit, or building	ISO 3166-2 subdivision	ISO 3166-1 alpha-2, such as US	The unit lives in line2, which field lists skip
Shopify MailingAddress	address1 and address2	province plus provinceCode	country plus countryCodeV2 (the older countryCode is deprecated)	Same line2 trap; name and code both present, easy to map the wrong one
QuickBooks Online	Line1 through Line5	CountrySubDivisionCode	Country, which Intuit's own request sample fills with "USA"	Three-letter country where others want two; transaction addresses reflow
Google Places	Components by type: street_number, route, subpremise	administrative_area_level_1, with longText "Massachusetts" and shortText "MA"	country, same longText and shortText split	Mapping longText where a code is expected

Read the table by column, not by row. The street column has three different shapes. The state column has names in some places, codes in others, and both side by side in three of them. Any pair of systems you connect disagrees on at least one of those columns.

Why does the suite number disappear?

This is the silent one, and in our experience it is the most expensive. Stripe and Shopify put the unit in a second line. HubSpot and Salesforce hold the whole street in one field. Someone builds a Shopify-to-HubSpot mapping, sees Address 1 and Street address, connects them, and ships. Every test order used a house address, so every test passes. The first apartment customer arrives as "12 Harbor St" with no "Apt 4", and nothing anywhere logs a problem because a street without a unit is a perfectly valid street.

The reverse direction has its own version. Going from a one-field street to a two-line receiver, people either stuff everything into line1 (tolerable) or try to split on a comma or the word "Apt" (dangerous, because units arrive as "#4", "Unit 4", "Ste 200", "Fl 3", or a bare number after a comma, and a rule written for one form mangles the others). A bad split puts half the street in line2, and some label printers and tax engines ignore line2 entirely.

The field-service cost is concrete. A dispatch app that shows "12 Harbor St" for a 40-unit building sends the crew to a lobby with no idea which door. The same logic behind required-field validation in field capture tools like Field to Flow applies here: a value the crew needs on site should be its own field that can be checked, not a fragment of a street string that one hop upstream may have dropped.

Why does Salesforce reject a state that looks right?

Salesforce is the loud one, and it is loud in specific, documented ways once state and country/territory picklists are turned on. Enabling them repurposes the old text State and Country fields as integration-value fields and adds picklist StateCode and CountryCode fields beside them. Salesforce's help states that integration values "default to the full ISO-standard state, country, and territory names," and that API integrations must match them. So "Massachusetts" in the text field works, "MA" in the text field fails, and "MA" in StateCode works.

Salesforce's list of picklist errors includes "A country must be specified before specifying a state value for field", which catches every integration that sends state without country because "everyone here is in the US." HubSpot's own Salesforce integration hits the same wall: its knowledge base (updated September 16, 2026) says the HubSpot option's internal value must match an existing Salesforce option, and the state must be available for the record's country, or the sync logs a mismatched state or country error.

Two quieter behaviors on the same page matter more than the errors:

• Create and update disagree. Salesforce's field-syncing table says that if you create a record with mismatched integration and code values, Salesforce updates the integration value to match the code. On update, the same mismatch is rejected with no changes saved. So a stale mapping that sends StateCode "NH" with State "Massachusetts" silently creates a New Hampshire customer, and only fails later when you try to fix it.
• Clearing country clears state. Remove a record's country code without removing its state code and Salesforce removes the state code and both integration values too. A sync that blanks country on a partial update wipes the state with it.

Admins can also edit integration values after enabling picklists, and Salesforce notes that records already saved keep the old value. An integration that worked last quarter can start failing because someone renamed an integration value in Setup.

What does QuickBooks do to an address on an invoice?

Intuit's API reference for the Customer entity carries a note that most integrations never read. When a physical address is updated from within a transaction, the API "flows individual address components differently": Line1 and Line2 are populated with the customer name and company name, and the original Line1 through Line5, city, state code, and postal code flow into Line3 through Line5 as free-format strings.

So the address on an invoice is not guaranteed to be the structured customer address. It can be a printable block where Line1 is a person's name. A sync that reads BillAddr off an invoice and writes Line1 to a CRM street field will, for those invoices, put "Dana Whitfield" where the street goes. Read addresses from the Customer object, and treat transaction addresses as print output.

QuickBooks is also the odd one out on country. Intuit's own create-customer sample sends "USA", while Stripe and Shopify want "US". A mapping that copies the country string across unchanged is wrong in one direction or the other.

The fix: one address shape at the boundary

This is the same pattern as phone numbers and dropdown values: stop translating system to system, and translate every system to one shape you own.

1. Define the canonical record. Seven fields: line1, unit, city, region_code, postal_code, country_code, and raw_input. Region is the state or province code (MA, ON). Country is ISO 3166-1 alpha-2 (US, CA). Postal code is text, always, because a Boston ZIP of 02110 turned into a number becomes 2110, the same failure covered in why CSV imports mangle IDs. Keep raw_input so you can reparse when your parser improves.
2. Parse once, at entry. Where addresses come in as one line (web forms, AI extraction from emails, phone intake), run them through a geocoder or address parser that returns the unit as its own component. Google's Places API types the unit as subpremise and gives state and country as both longText and shortText. Take shortText for the code fields. Do not parse again downstream.
3. Render per receiver, from the canonical record only. For HubSpot, write line1 plus ", " plus unit into Street address, and the codes into the code properties. For Salesforce, write StateCode and CountryCode, never the text fields, and always send country with state in the same call. For Stripe and Shopify, unit goes to line2 or address2. For QuickBooks, unit goes to Line2 and the country string is whatever your QuickBooks company actually uses, checked once.
4. Fail closed on unknown regions. If a region code does not exist for the country, hold the record and alert. Do not let the receiver pick. Salesforce's create behavior shows why: the receiver's default resolution is not your intent.
5. Keep one test record. An address with a unit, a leading-zero ZIP, and a non-US country with provinces. "100 King St W, Suite 200, Toronto, ON" plus a Boston "02110" record will catch the line2 drop, the ZIP-as-number bug, the name-versus-code bug, and the missing-country bug in one run.

If records already carry mixed shapes, match before you fix. The address is a weak match key on its own, as the matching ladder for records without a shared ID explains, so repair addresses on records you already linked by email or ID, and backfill unit from the source system's line2 rather than by guessing.

How to start

Pull 50 records from your CRM where the source system has a line2 value, and check how many CRM records contain it. That single count tells you whether the silent failure is live. If it is above zero, add the canonical address step at the boundary before touching anything else. If your address data feeds dispatch, tax, or mailing and you want a second pair of eyes on the mapping, that is the kind of cleanup we do in data intelligence work, and you can reach us here.