Your invoice shows ₹50,000. The general ledger shows ₹49,800. You spend two hours tracing line items, tax codes, and payment receipts. This isn't carelessness—it's what happens when invoice data passes through nine separate handoff points between your CRM, billing platform, and accounting software, and each one has its own interpretation of what 'invoice' means. Most businesses discover these breaks during month-end close, audit prep, or tax season. By then, fixing them costs hours of manual work and creates gaps in your compliance trail. This guide maps all nine handoff points, shows you exactly where data breaks, and gives you an audit checklist to catch mismatches before they become problems. Why invoices and GL entries stop matching When you issue an invoice, it doesn't move as a single package from one system to another. Instead, it's dismantled into fields—quantity, price, tax, date, GL code, approval status—each routed to a different system via API, CSV, or manual entry. Each system has defaults, validation rules, and rounding logic. A tax field that rounds 0.5% one way in your billing tool rounds the other way in your accounting platform. A date that updates in your CRM doesn't trigger a corresponding update in your GL. A payment recorded in your bank feed never mentions the invoice ID that created it. The result: your invoice and GL entries are siblings raised by different parents. They share some DNA but diverge in ways that are invisible until reconciliation day. Handoff 1: Quantity entry and line-item decimals Where it breaks: CRM to billing platform. Most CRM systems store quantity as a decimal (12.5 units). Most billing platforms accept decimals, but some round them—12.5 becomes 12 or 13 depending on the rounding rule. If your CRM sends 12.5 but your billing platform rounds down to 12, the invoice shows 12 units and the GL reflects 12 units, but your CRM still shows 12.5 as 'invoiced.' When you pull a reconciliation report from each system, quantities won't match. Audit step: Pull your last 50 invoices. For each one, export the quantity from your CRM and the quantity from your billing platform. Do they match line-by-line? If not, check whether your billing platform has a decimal-rounding rule (check settings → quantity precision or defaults). Document the rule and apply it retroactively to historical data if needed. Handoff 2: Tax field interpretation and calculation order Where it breaks: Billing platform to accounting software. Tax is never just a number—it's a calculation. If you sell ₹1,000 at 18% GST, is tax ₹180, or is the invoice total ₹1,180? Does tax apply before or after a discount? In some systems, you enter the tax rate and the system calculates tax. In others, you enter the tax amount directly. When data moves from billing to accounting, these interpretations collide. Example: Your billing platform calculates tax as (unit price × quantity) × tax rate. Your accounting software expects (unit price × quantity × tax rate) + (any adjustments). If an adjustment exists in your billing platform, the accounting software won't see it unless it's explicitly passed as a separate line item. Audit step: Pick 10 invoices with different tax rates (0%, standard rate, reverse charge, exempt). For each invoice, manually calculate tax two ways: first using your billing platform's documented formula, then using your accounting software's formula. Do the totals match? If not, document the difference and create a lookup table that shows which invoices need manual adjustment. Handoff 3: Currency conversion and rounding Where it breaks: Multi-currency invoices syncing from billing to GL. If you invoice in SGD but your GL is in INR, someone has to convert. Your billing platform might use today's exchange rate. Your accounting software might use the rate from the invoice date. A third system (your bank feed or payment processor) uses yet another rate. All three can be technically correct, and all three can produce different GL entries. When you record a payment, the amount received rarely matches the invoice total exactly, especially if the payment processor charged a fee or the exchange rate moved. Your GL now shows a discrepancy that looks like a data error but is actually a currency timing issue. Audit step: Pull all multi-currency invoices from the last 90 days. For each one, find the invoice amount in your billing platform (in original currency), the GL entry (in base currency), and the payment received (in whatever currency your bank recorded it). Document the exchange rates used at each step. Calculate whether the difference between GL and payment is explained by currency conversion or represents a true sync error. Handoff 4: Date stamps—invoice date vs. GL date vs. recognition date Where it breaks: Between billing and accounting for revenue recognition and payment matching. An invoice has at least three dates: the date it was created (invoice date), the date it was sent (delivery/service date), and