When the CRM and the ledger disagree, who wins?

Five conflicts worth settling before you connect anything. Each one is a business decision disguised as a field mapping.

Most integration projects start by mapping fields. deal.amount goes to subscription.unit_price goes to Invoice.Line.Amount. It feels like the work, and it's about 10% of it.

The other 90% is a set of decisions that no schema can answer, that different departments answer differently, and that will be made implicitly by whoever builds the integration if nobody makes them explicitly first. Here are five worth settling in a meeting before anyone writes code.

1. When is a deal actually won?

The options: the stage changes to Closed Won, or a Quote is marked accepted, or a contract is signed in your e-sign tool.

These are different moments. Reps move stages for pipeline-hygiene reasons — end of quarter, forecast calls, a manager asking them to clean up. A stage change is a sales event. A signature is a commercial event. If you trigger billing on the stage change, you will eventually bill someone who hasn't signed.

The opposite failure is real too: if you wait for a signature that lives in a system you don't read, subscriptions get created late and the first invoice is short.

Settle it as: the trigger, plus what happens if the deal moves back out of Closed Won after the subscription exists. That second half is the one everyone forgets, and it's the one that generates a live subscription for a deal that no longer exists.

2. When does the subscription start?

Close date, signature date, go-live date, or a date the rep types into a field.

For a SaaS company with onboarding, these can be weeks apart, and the gap is money. Start on close date and you're billing for a period the customer wasn't using the product — which produces a support ticket and, usually, a credit. Start on go-live and you're carrying unbilled revenue for however long implementation takes.

Settle it as: which field carries the date, what happens when that field is empty, and whether the first period is prorated.

The empty-field case matters more than it sounds. If the rule is "use the date in billing_start_date" and 30% of deals have it blank, you need a fallback that's written down — not one the integration picks silently.

3. Which system owns the price?

The catalog price in the CRM, the catalog price in billing, or whatever the rep typed on the line item.

If reps can discount, then the line item is the truth and billing must reflect it. If they can't, then the catalog is the truth and any deviation in billing is someone in finance having changed a number sales didn't agree to. Both are defensible policies. What isn't defensible is not knowing which one you have, because then a mismatch is unclassifiable — you can't tell a legitimate discount from an error.

Settle it as: can reps override price? (Never / Freely / With approval.) Then: if the deal and the subscription disagree, do we correct the deal or the subscription?

The answer to that last question is usually "the deal", because the subscription has already generated an invoice the customer has seen — but say it out loud, because the instinct of most engineers is to make the newer record win, and the newer record is usually the wrong one.

4. Which system owns the customer record?

Name, billing address, currency, tax id, payment terms. The CRM has a version. Billing has a version. The ledger has a third.

The wrong answer is "whichever updated last", which is what most syncs do by default and which produces a record that flips back and forth between two systems every night. Genuinely — bidirectional sync with last-write-wins on a field two people edit is an infinite loop with extra steps.

Settle it as: a per-field owner, not a per-record owner. Sales owns the company name and the contacts. Finance owns the billing address, tax id, and payment terms. Billing owns currency. Then each field flows one direction only.

5. When does revenue hit the books?

Nightly, at close, or in real time as invoices are issued.

This is the one where the accountant has a strong opinion and is usually right. A nightly batch at a fixed time gives them a predictable place to review. A trickle of invoices arriving all day gives them a moving target and makes "what changed today" unanswerable.

Settle it as: the cadence, the cut-off time, and — the important bit — what happens to a correction that arrives after the period is closed. Does it post to the current period, or does it wait? A closed period is a hard boundary in accounting, and an integration that writes into one is a genuine problem, not an inconvenience.

Why these five and not fifty

Because these five are where the money differs. Everything else — a mismatched phone number, a stale industry field — is annoying. These five each produce a wrong invoice, a wrong ledger entry, or a wrong revenue number.

And notice what they have in common: each is a sentence, not a mapping. "We bill from the accepted quote." "Subscriptions start on the date the rep enters, defaulting to close date." "Finance owns billing address." A good integration should be describable in five sentences like that, and if yours can't be, then the rules are scattered across six automations and nobody knows what the system does.

Write them down first. The mapping is easy once the decisions exist.

TruelineHQ asks these questions during setup and shows the answers back as plain sentences you can change later. See the five questions.