You invoiced a client for ₹12,500. Your CRM shows ₹12,500. Your GL shows ₹12,487. The ₹13 difference vanishes into the audit log, and by the time you find it, you've reconciled three other invoices and the gap has buried itself under 47 more transactions. This is not a rounding error—it's a data architecture problem that appears the moment your CRM stops talking to your accounting tool. The real cost isn't the ₹13. It's the 6 hours you spend per month hunting these gaps, the 40% of invoices that diverge by more than 2%, and the risk that a 2% error compounds across 200 invoices into a ₹50,000 reconciliation nightmare. We'll walk through one invoice and show you the nine exact points where sync fails, then build a 90-minute audit you can run today. The invoice that becomes three different numbers Let's follow a real example. A retainer client in Malaysia owes ₹12,500/month for Q1. The invoice is split: 30% SST (Service and Sales Tax, Malaysia's GST equivalent, 6%), 70% material cost. In your CRM, you record the gross total. In your billing module, the system applies tax. In GL, it posts to three accounts: revenue, SST payable, and a retained-earnings offset for the currency rounding difference. By the time one invoice moves from CRM to billing to GL, it has been touched by at least five different code paths. Each one rounds differently, and each difference is small enough that manual reconciliation misses it—until you have 200 invoices and 47 missing entries. Here are the nine places the ₹12,500 diverges: 1. Currency conversion timing You invoice in MYR. Your GL is in INR. If the CRM converts at transaction time (3.2 MYR = 1 INR) and GL converts at settlement time (3.25 MYR = 1 INR), the difference is ₹191. If the sync happens in batch and one invoice is included at 3.2 and another at 3.25, the divergence snowballs. Most CRM-to-GL connectors do not log which exchange rate was used, making it impossible to audit after the fact. Fix: Force all currency conversions to use a single source (e.g., European Central Bank midnight rate) and log it in the GL. This removes the timing arbitrage. 2. Tax line-item rounding Your invoice splits into two line items: ₹8,750 (material) and ₹3,750 (service). The tax is calculated per line item in the CRM, rounded to the nearest paisa. The GL recalculates the total tax and rounds it once. The difference is ₹0.07—invisible until you reconcile. If you have 50 line items, each with rounding, you can easily lose ₹3–5 per invoice. Fix: In your invoicing tool , set tax rounding rules explicitly: either round per line item (and then sum) or sum first and round once. Document which method you use and ensure the GL posting uses the same logic. Most accountants prefer sum-first-round-once because it minimizes rounding artifacts. 3. Proration across billing periods The client signed on January 15. Your billing cycle is monthly. The first invoice covers 17 days of January (Jan 15–31) and should be prorated. Your CRM calculates the daily rate as ₹12,500 / 30 = ₹416.67 * 17 = ₹7,083.39. But your GL uses a 360-day year, so it calculates ₹12,500 / 360 * 17 = ₹589.58. The difference is ₹1,994—a real error, not a rounding artifact. Fix: Define your proration method once (30 days per month, 365 days per year, or actual days) and enforce it in both the CRM and the GL configuration. If you use a billing system like Orin's invoicing , set the proration rule there and ensure the GL posting rule references the same calculation. 4. Partial payment and credit reversal The client pays ₹10,000 on the ₹12,500 invoice. Your CRM records the payment and updates the invoice balance to ₹2,500. Your GL posts the payment as a debit to cash and a credit to accounts receivable. But if the sync happens out of order, the GL might post the full invoice first, then the payment in a separate batch. If the batches diverge, GL shows ₹12,500 in AR and ₹10,000 in a suspense account instead of a clean ₹2,500 AR balance. Fix: Never sync payments separately from invoices. Always sync them as a unit: invoice, then payment, verified in a single transaction before it hits GL. If your system does not support atomic syncs, add a reconciliation step that prevents GL posting until both invoice and payment are in the queue. 5. Multi-currency line items on a single invoice You invoice a client who operates in three countries. One line item is in SGD (Singapore), one in MYR (Malaysia), one in IDR (Indonesia). Your CRM sums them in the base currency. Your GL posts them to three separate AR accounts (one per currency). If the sync doesn't preserve the per-currency line item detail, GL loses the ability to reconcile AR by currency, and you cannot match it to the bank statement (which shows SGD in, MYR in, IDR in separately). Fix: Invoice single-currency clients on single invoices. If you must bill in multiple currencies, split into separate invoices—one per currency. This forces the GL to post clearly and makes reconciliation possible. 6. D