You send an invoice from your CRM for ₹10,000. Your accounting team receives it. Month-end close arrives, and the GL shows ₹9,850. Nobody knows why. It's not fraud, not stupidity—it's nine separate points where invoice data diverges between systems, and each one compounds the next. This isn't theoretical. Teams using separate CRM and accounting software lose 2–4 hours per week reconciling drift, and larger teams face audit findings because the audit trail doesn't connect the dots. The fix isn't a new tool—it's mapping where the breaks happen and building a repeatable audit process. Break 1: Tax calculation method (compound vs. single-step) Your CRM calculates tax on the net subtotal. Your accounting software calculates it on the subtotal minus early-payment discounts. Same invoice, different tax amount. Example: Subtotal ₹10,000, 15% discount (₹1,500), tax at 8%. CRM: Tax on ₹10,000 = ₹800. Total: ₹9,300. GL: Tax on ₹8,500 (after discount) = ₹680. Total: ₹9,180. Drift: ₹120 (1.3%). Audit fix: Document your tax calculation sequence in a reconciliation template. Specify: tax on original amount before any discount or tax on amount after discount . Make that rule visible to whoever configures your accounting software's invoice sync. Break 2: Rounding rules (banker's rounding vs. standard) Line-item taxes round differently. CRM uses standard rounding (0.5 up). Accounting software uses banker's rounding (0.5 to nearest even). Across 20 line items, this adds ₹15–45 in drift per invoice. Example: Three line items, each ₹3,333.33 at 8% tax. Line 1 tax: ₹266.666... → rounds to ₹267 (CRM) or ₹266 (GL). Line 2 tax: ₹266.666... → rounds to ₹267 (CRM) or ₹267 (GL). Line 3 tax: ₹266.666... → rounds to ₹267 (CRM) or ₹266 (GL). Total drift: ₹2–6 per invoice. Audit fix: In your sync setup, specify one rounding rule globally. If your accounting software rounds per-line, configure your CRM to match. Document it in the integration settings and review it quarterly. Break 3: Discount application order (before vs. after tax) A ₹500 line-item discount. Is it applied before tax is calculated, or after? CRM and GL often disagree. Before tax: ₹(10,000 − 500) × 8% = ₹760. After tax: ₹(10,000 × 8%) − 500 = ₹300. Across invoices, this creates a phantom 2–6% monthly variance. Audit fix: Establish a single discount sequence rule: line-item discounts always before tax, invoice-level discounts always after line-item tax but before invoice-level tax . Map this in your CRM's discount fields and in the accounting software's import template. Test one invoice end-to-end before going live. Break 4: GL account mapping (line-item level) Your CRM has a product category 'Consulting.' Your accounting software has two GL accounts: 4001 (billable) and 4002 (non-billable). The sync rule says 'use 4001.' But yesterday, you created an invoice with a discount line that the accountant wants to post to 4003 (discounts). The sync doesn't know about 4003, so it defaults to 4001. Your GL is now out of balance with the invoice register. Audit fix: Audit your sync mapping rules quarterly. Print them out. For each product, service, discount, and payment term in your CRM, confirm that the GL account in the sync rule matches what your accountant actually uses. If there's a mismatch, the invoice won't reconcile, and you'll find it weeks later during close. Break 5: Multi-currency conversion (timing and rate source) You invoice a Singapore client ₹50,000. The CRM converts it to SGD at 1.05 (the rate when the invoice was issued). The accounting software converts it at 1.04 (the rate when the sync happened, 6 hours later). The GL shows a ₹476 exchange gain/loss that the invoice doesn't mention. Audit fix: Always sync invoices immediately after they're sent, not in a batch hours later. If you batch-sync, fix the exchange rate in the sync rule to the invoice date, not the sync date. Document which rate source (ECB, RBI, your bank) the sync uses, and update it annually. Break 6: Partial payment application (split across invoices) A customer pays ₹5,000 against two invoices (₹3,000 and ₹2,500). Your CRM applies it correctly. But your accounting software's sync algorithm applies it to invoice 1 first, then invoice 2. The timing of when each invoice is marked 'paid' differs, so your DSO (days sales outstanding) and aging report show different numbers. Audit fix: Document the payment application logic in your GL. Specify: payments applied oldest-invoice-first or manual allocation required . If manual, add a review step before the GL is posted. If automated, test it with a multi-invoice payment scenario monthly. Break 7: Tax code or rate change mid-sync On January 15, Singapore's GST changes from 7% to 8%. Your CRM is already using 8%. But your accounting software's sync rule still references the old 7% tax code (because nobody updated the integration). Invoices issued on January 15 sync with mismatched tax rates. Audit fix: Create a calendar alert for tax rate changes in every j