Skip to main content

How do I sync Salesforce Account billing addresses for AR?

Loopfour's Salesforce integration reads the Account object's Billing* fields — BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry — directly, since Salesforce has no separate billing-address object. The integration polls Account records rather than reacting to webhooks, so a workflow needs to schedule that poll rather than expect real-time updates.

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

Part of the finance integrations guide.

Object readAccount, using its Billing* prefixed fields (a compound BillingAddress on the Salesforce side)
Sync mechanismPolling only — no webhook/event handler exists for Salesforce in this integration
Field names to mapBillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry
ContrastHubSpot exposes the same concept as flat, non-prefixed fields (address/city/state/zip/country) and supports webhooks; Salesforce does neither

Why Account, not a separate billing object

Salesforce doesn't have a dedicated billing-contact or remittance-address object in its standard schema — a customer's billing address lives directly on the Account record, as a set of Billing*-prefixed fields (BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry) that together make up what Salesforce calls the BillingAddress compound field. Loopfour's Salesforce integration reads these fields straight off the Account object rather than a separate related record.

Setting up the sync

Map each of the five Billing* fields individually — there's no single compound value to pull in one step through the integration's Account actions. Because the Salesforce integration has no webhook handler (unlike HubSpot's contact/company change events in this same matrix), the workflow has to poll Account records on a schedule rather than react to an update the moment it happens; how frequently depends on how quickly billing-address changes need to reach downstream AR documents.

What to check before going live

Confirm which Account record actually represents the paying entity — Salesforce Accounts commonly nest parent/child hierarchies for large customers, and the field values live on whichever specific Account record is the billing party, not necessarily the top-level parent. Also confirm the poll interval against how fast your team needs an address change (a customer moving, a re-incorporation) to reach an invoice before it goes out with a stale address.

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 Account Billing* fields to map for AR

Salesforce fieldCompound componentMaps to
BillingStreetBillingAddress.streetAddress line 1
BillingCityBillingAddress.cityCity
BillingStateBillingAddress.stateState/province
BillingPostalCodeBillingAddress.postalCodePostal/ZIP code
BillingCountryBillingAddress.countryCountry

Frequently Asked Questions

BillingAddress exists as a compound field in the Salesforce UI and in some API responses, but the individual Billing* fields are what most integrations, including this one, read and write directly — map each one separately.

Salesforce has no webhook/change-event handler wired up in Loopfour's integration, unlike HubSpot in this same matrix — Account data is read on a poll, not pushed on update.

They're independent compound fields — a populated BillingAddress with an empty ShippingAddress is normal and doesn't affect AR sync, which only reads the Billing* fields.

Sources

Related