You invoice a client for ₹10,00,000. The receipt lands in your bank account at ₹9,95,000. Your invoicing software confirms ₹10L. Your GL shows ₹9.95L. Finance swears they posted it correctly. Payroll and tax withholding software read different numbers from the same transaction. This is not chaos. It is the natural consequence of how modern invoicing systems talk (and don't talk) to accounting systems. The drift is real, repeatable, and traceable—but only if you know where to look. Why invoice totals diverge from GL postings When an invoice leaves your invoicing tool and arrives in your general ledger, it crosses a boundary. On one side, the invoice is a business fact. On the other, it becomes a set of GL line items. Between those two worlds live nine places where the math stops aligning. Most teams catch drift only during month-end close—sometimes weeks after the invoice posted. By then, the payment has already landed, tax withholding has been allocated, and related invoices have been issued. One small drift now costs hours of audit work later. Root cause 1: Multi-currency rounding spreads the error You invoice a Singapore client for SGD 15,000. Your invoicing software converts it at 57.50 (the rate you quoted). The GL uses the bank settlement rate from yesterday: 57.4980. The invoice shows ₹8,62,500. The GL posts ₹8,62,470. Difference: ₹30. Multiply this across ten invoices in different currencies, and you accumulate ₹500–₹1,000 per month. Over a year, that's a ₹6,000–₹12,000 reconciliation problem that no single invoice caused. Most invoicing software lets you choose which exchange rate to use: the rate at invoice date, the rate at payment receipt, or a corporate rate you set manually. Your GL software may enforce a different rule altogether. The gap exists by design. The audit signal: Export your invoices and GL transactions by currency. Calculate the conversion variance for each. If the variance exceeds ±0.2%, investigate whether both systems are using the same rate table and timing rule. Root cause 2: Tax line GL splits fail to reconcile Your invoice itemizes: Services: ₹8,50,000 GST (18%): ₹1,53,000 Total: ₹10,03,000 Your invoicing software posts this as two GL lines: one to revenue, one to tax liability. But if your GL chart of accounts splits revenue by service type (say, consulting vs. support), and your invoicing software only knows one revenue account, the split is lost. The tax line posts correctly. The revenue line posts to the wrong place, or worse, to a clearing account. Some invoicing tools post the gross amount to revenue and then a negative adjustment for tax. Others post net revenue and tax separately. If you switch tools mid-year, or if you manually override a GL mapping, the logic breaks. The audit signal: For every invoice, verify that Revenue + Tax Liability = Invoice Total in the GL. Use a report that groups by invoice ID. Run it monthly. Any invoice where this does not hold has a GL mapping error. Root cause 3: Partial payment posting splits the invoice across months Client pays ₹5,00,000 of a ₹10,00,000 invoice in January. The remaining ₹5,00,000 arrives in February. Your invoicing software still shows the invoice as a single ₹10L transaction. But your GL may have posted two separate entries: one in January (revenue + partial payment clearing), one in February (revenue adjustment + partial payment clearing). If the GL uses accrual accounting correctly, both months should net to the same ₹10L. But if there is a timing mismatch—say, the invoice date differs from the revenue recognition date—the GL can show ₹10L in one month and ₹9.5L in another. This is especially common when your invoicing tool uses invoice date for revenue recognition, but your GL uses payment date (or vice versa). The audit signal: Group GL revenue by invoice ID and payment date. For any invoice where you received multiple payments, verify that all GL lines net to the original invoice total. If they don't, you have a revenue recognition timing issue. Root cause 4: Overpayments and clearing confuse the balance Client overpays an invoice by ₹5,000. Your invoicing software shows the invoice as paid. Your GL software creates a credit memo or overpayment liability account. The invoice total is still ₹10L. But if your GL posting logic treats overpayments as a separate transaction (rather than a contra to the original invoice), you end up with: Invoice GL total: ₹10,00,000 Overpayment GL total: ₹5,000 Net: ₹10,05,000 instead of ₹10L When you apply that overpayment to the next invoice, the GL reverses it—but if the reversal posts to a different GL account or a different month, your month-end reconciliation breaks. The audit signal: Export all GL accounts that mention 'overpayment', 'prepayment', 'credit memo', or 'clearing'. For each, verify that overpayments are either (a) netted against the original invoice in the same GL entry, or (b) have a matching reversal in the month they are applied. Any overpayment that lingers