Your CRM shows invoice total: ₹50,000. Your GL shows posted amount: ₹45,237. The accountant is on the phone. You trace backwards through email chains, payment screenshots, and bank statements. By the time you find the break, you've lost two hours and learned nothing repeatable. The problem is not one break—it's nine. Each one is normal and defensible. Together they shred reconciliation and kill audit confidence. Here's where they live, traced through a single invoice's journey from sales quote to general ledger. Break #1: Quote discounts don't sync to the invoicing system Your CRM quote shows: Line items: ₹60,000 Volume discount applied in CRM: −₹10,000 (16.7%) Quote total: ₹50,000 Your invoice system receives the line-item total (₹60,000) but not the discount logic. The discount lives only in the CRM deal record, not in a structured data field the invoicing system reads. Result: the invoice drafts at ₹60,000. Someone catches it, manually adjusts it back to ₹50,000, and documents the change nowhere. Audit impact: Invoice amount is correct, but GL line shows a manual adjustment with no description. When LHDN or your auditor asks "why did this line item change between quote and invoice?", you have no system trace. Fix: Store discounts as discrete line items in your CRM, not as a flat percentage. A proper CRM pipeline and quotes tool should sync discount codes, amounts, and reason to the invoicing system as structured data. Break #2: Tax codes don't match line-item nature Your invoice has four line items: Consulting hours (6% SST) Software license (exempt) Training delivery (6% SST) Reimbursable expenses (no tax) Your invoicing system has a single tax rule: "6% SST on everything." So it applies 6% to the software license (wrong), exempts reimbursables (correct by accident), and now the invoice total is ₹51,200 instead of ₹50,600. The accountant posts it at ₹50,600 because she knows the rule. The system shows ₹51,200. Delta: ₹600. Audit impact: GL shows a deferred tax adjustment no one can explain. Worse: if this happens 50 times a month, you've got ₹30K in untraced GL corrections by quarter-end. Fix: Use invoicing software that ties line-item type to tax codes . Each line item should carry its tax classification from quote to invoice to GL, not be overridden at invoice time. Break #3: Manual discount codes don't post to GL The sales rep applies a ₹5,000 "customer loyalty" discount at invoice time (not in the quote—it was a last-minute negotiation). The invoice total drops to ₹45,000. But the discount is coded as a generic "Other" deduction in the invoicing system, not to a specific GL account. The accountant posts it to Sales Discounts (revenue side) instead of COGS Adjustments (cost side), or vice versa. CRM says ₹45,000 revenue. GL says ₹45,000 revenue but disagrees on what was discounted and why. Audit impact: Auditors see revenue is correct but the discount trail is broken. They flag it as a control gap. Fix: Require all discounts to be applied in the CRM quote stage, not at invoice time. If a late discount is unavoidable, tie it to a named GL account at the moment of application. Break #4: Payment settlement lag isn't reflected in invoice date You issue invoice on Jan 15 for ₹50,000. Customer pays via Stripe on Jan 16. Stripe settles to your bank account on Jan 18 (2-day settlement window). Your accounting system posts the invoice revenue on Jan 15 (correct) but doesn't record the cash until Jan 18. This is normal. But if you're reconciling CRM revenue to GL on Jan 17, you see ₹50,000 in Accounts Receivable (GL) but no cash (bank shows nothing yet). You then adjust the AR manually to ₹0 when the payment clears, creating a 3-day GL mismatch. Audit impact: AR aging report is temporarily inaccurate. If you generate it on Jan 17, it shows ₹50,000 outstanding when it's actually in flight. Fix: Automate reconciliation on bank settlement date, not invoice date. Accounting software should sync payment status from your processor (Stripe, Razorpay) to AR automatically, clearing it only when funds actually hit your bank. Break #5: Payment processor fees are silently deducted Invoice total: ₹50,000. Customer pays via Stripe. Stripe's 2% processing fee: ₹1,000. You receive ₹49,000 in your bank account on Jan 18. Your CRM/invoicing system shows the invoice as "paid in full: ₹50,000." Your GL shows ₹49,000 cash received. The ₹1,000 fee is somewhere in your P&L, maybe under "Fees" or "Merchant Services." Now trace it: Is that fee tied to the invoice? Is it deducted from revenue or posted as an expense? If 50 invoices were paid via Stripe that month, did you deduct 50 × 2% from 50 different invoices, or did you batch-adjust revenue once? The CRM doesn't know. The GL doesn't care. But the two numbers will never match without manual reconciliation. Audit impact: Revenue in CRM is gross (pre-fee). Revenue in GL is net (post-fee). This is defensible accounting, but the link between them is invisible. Fix: Record payment fees