Most businesses think their invoice data flows cleanly: CRM → billing system → accounting software. In practice, that invoice fractures into nine separate pieces of truth, each one drifting slightly further from the others until your finance team reconciles by hand every month. We mapped those nine breaks by tracing a real invoice—one customer, one product, one currency—through a typical stack: CRM pipeline , invoicing , and a general ledger. Here's where it all goes sideways. Break 1: Contact vs. Bill-To vs. GL Entity Your CRM stores the customer record: name, address, tax ID, payment terms. The billing system creates a bill-to address. The GL expects a supplier or customer entity code. Three systems, three places to define "who this invoice is for." When you have a holding company (invoice from Entity A, ship to Entity B, bill to Entity C), most integrations pick one and lose the others. If your CRM links to Entity A but your billing system defaults to Entity B, the GL never sees the link between the invoice and the true obligor. A subordinate company's revenue appears orphaned in consolidated reporting. Audit point: Pull ten random invoices. Check the bill-to address in your CRM against the customer name in your accounting software. Do they match character-for-character, or is one using a shorthand or acronym? If they diverge, GL reconciliation will require a manual mapping table. Break 2: Tax ID Storage and Validation Your CRM has a "Tax ID" field. Your billing system has a different tax ID field—maybe "VAT Number", maybe "GST ID", maybe "NPWP". Neither validates in real-time. By the time the invoice lands in your GL, the tax ID is either missing, wrong, or stored in an unrecognized format. In regulated markets (Malaysia's MyInvois, Indonesia's e-Faktur, Singapore's IRAS), an invalid or mismatched tax ID makes the entire invoice fail submission. Your invoice sits in a limbo state: marked as issued in billing, flagged as incomplete in compliance, orphaned in the GL. Audit point: Open your most recent invoice. Pull the customer's tax ID from three places: (1) your CRM contact record, (2) the billing system's customer master, (3) the GL customer account. If all three are not identical, you have a data sync problem. Now check whether the tax ID format is correct for the customer's country (NPWP for Indonesia is 15 digits; if yours is 16 or 12, it will fail validation). Break 3: Line-Item Product Codes and GL Account Mapping You sell "Website Redesign" in your CRM. Your billing system translates that to SKU "WEB-REDES". Your GL expects a revenue account code: "4100-Design-Services". If the mapping is manual (a spreadsheet somewhere), it breaks every time someone renames a product or adds a new service line. The invoice shows the customer what they bought. The GL shows your accountant where the money should land in the P&L. If the mapping is missing or stale, that line item lands in "Miscellaneous Income" instead of the correct revenue bucket. For contract revenue recognition or grant accounting, a single misclassified line item can throw your entire month's close. Audit point: Export a recent invoice. For each line item, verify: (1) the product name and SKU match your billing system, (2) the GL account code appears in the exported invoice or your integration log, (3) the GL account still exists (accounts get merged or deprecated). If any are missing, your mapping is incomplete. Break 4: Multi-Currency Exchange Rates Your CRM records an invoice in USD. Your billing system applies the day's exchange rate: 1 USD = 4.20 SGD. Your GL expects the invoice amount in both currencies, with FX gains or losses posted to a specific account. But which exchange rate? Spot rate at invoice date? Spot rate at due date? Spot rate at payment date? Bank's rate, or your company's internal rate? If your CRM and billing system use different rates—or if one system rounds to 2 decimals and another rounds to 4—your GL will show a variance that your accountant must manually investigate. At 50 invoices a month in five currencies, this becomes a permanent reconciling item. Audit point: Find an invoice in a non-home currency from more than two weeks ago. Recalculate the GL amount using three different rates: (1) the CRM's recorded rate, (2) the billing system's rate, (3) your bank's spot rate on invoice date. If all three differ, you have an FX variance trail. Check your GL for a "Foreign Exchange Gain/Loss" account; if it's empty or zero, your sync is masking the variance, not reporting it. Break 5: Tax Calculation and Allocation Your invoice is 10% tax. Your CRM shows gross amount. Your billing system calculates tax as a separate line. Your GL posts gross to revenue and tax to a liability account. But which tax? If you sell in multiple countries on the same invoice, the tax rate might vary by line: 0% for goods, 6% for digital services, 8% for consulting (Malaysia's SST rates). A single invoice might have three tax rates and three GL po