You pull the GL balance and the CRM invoice total. They do not match. The difference is ₹5K or ₹50K or ₹500K depending on scale, and you have no idea where it vanished. Finance wants to close the month. You have 90 minutes to find the break. This is not a data quality issue—it is a data handoff issue. Invoices do not lose money in the CRM or the GL. They lose it in the translation between them. Nine specific points where bits of the transaction get rounded, remapped, split, or silently discarded. This playbook maps all nine, gives you a checklist to audit each one, and shows you exactly how to close the gap. Why invoices and GL never agree (without a checklist) Your CRM holds invoice line items. Your GL holds account postings. Those two things should be mirrors of each other. They are not, because the systems do not speak the same dialect. A line item in the CRM might say: Product XYZ, ₹1,000, 18% GST, customer India. The GL needs to post to: Revenue XYZ, ₹1,000; GST Payable, ₹180; Receivables, ₹1,180. But between those two statements, five assumptions have to hold true: The tax rate is actually 18%, not a different rate for this customer or geography. Rounding on ₹180 tax matches rounding on the line total. The currency conversion (if any) happened at the same rate for both the line and the tax. The revenue account is mapped correctly from the product code. No credit note or discount was applied after invoice generation. Break any one of these, and your total diverges. Break three or four, and you have a ₹50K phantom. Sync break #1: Tax rate mismatch This is the fastest source of divergence and the easiest to spot. Your CRM invoice shows 18% GST. Your GL tax posting shows 12%. One of three things happened: The customer record has a different tax code than the product or order. The invoice was generated with the customer's default rate, not the product's. A tax exemption or special rate was applied after invoice generation , and the GL posting picked it up but the CRM total did not. The invoice template defaulted to the wrong rate and the GL was corrected manually. Audit step: Pull 10 invoices from the last 30 days. For each one, check three places: the CRM invoice line, the customer record, and the GL posting. Write down the tax rate shown in each. If they diverge, ask which one is source of truth for your month-end close. Usually it is the GL; work backward to find where the CRM went wrong. Sync break #2: Line-item rounding You invoice for ₹1,000 / 3 = ₹333.33 per item across three lines. Three items × ₹333.33 = ₹999.99. You invoice for ₹1,000, so one line gets ₹333.34. The CRM total reads ₹1,000. The GL sees ₹999.99 from the line-level postings, then a ₹0.01 adjustment line. That adjustment is invisible in the CRM. Multiply this across 50 invoices and you have ₹0.50 in phantom differences. Usually not material, but if your GL is set to post rounding adjustments to a separate account, and your CRM does not track it, month-end reconciliation fails. Audit step: Export a sample invoice from your CRM. Calculate the sum of all line totals (including tax on each line, if your system calculates tax line-by-line). Compare it to the invoice total shown in the header. If they differ by more than ₹0.05, your system has a rounding rule. Check if the GL posting includes a rounding-adjustment line. If not, it is hiding in the revenue or tax accounts. Sync break #3: Currency conversion timing and rates You invoice a US customer for $1,000 on March 1 at an exchange rate of 83 INR/USD = ₹83,000. Your GL posts ₹83,000 to receivables. Then on March 5, the invoice moves to "paid" and your payment platform (Stripe, Razorpay, whatever) settles at 82.50 INR/USD = ₹82,500. You post a ₹500 exchange-gain/loss to the GL. But your CRM invoice still shows ₹83,000 as the transaction amount. Now your CRM total does not match the GL total. The GL is ₹500 lower, and that ₹500 is sitting in an exchange-gain line item that the CRM does not see. Audit step: Identify all invoices with a non-home currency. For each one, check: (a) the exchange rate used when the invoice was generated; (b) the exchange rate shown in the GL posting; (c) the exchange rate applied when payment settled. If (a) and (b) differ, you have a conversion-timing break. If (b) and (c) differ, you have a settlement-vs-accrual gap. Sync break #4: Tax-code mapping (product ≠ GL account) Your CRM stores tax as a simple percentage: 18% on this line. Your GL needs to post to a specific tax account: "GST 18% Payable – CGST" or "GST 18% Payable – SGST." If your CRM has a tax-code field and your GL mapping is wrong, the tax amount will post to the wrong account, but the total invoice amount is still correct. The CRM and GL both show ₹1,180, but the GL has it in the wrong tax bucket. This does not cause the total to diverge, but it wrecks your tax filing. However, if your GL mapping is missing for a tax code (i.e., you used a tax rate that has no GL account), the posting fails silen