You send an invoice for ₹50,000. Your invoicing tool shows ₹50,000. Your accountant opens QuickBooks (or Xero, or Wave) and finds ₹49,998. Three days of your time later, you discover a rounding rule fired on line-item tax, or FX conversion happened twice, or a discount applied in one system and not the other. By then, the client has paid the invoice amount, your GL is out of balance, and you're manually journaling corrections. This isn't rare. When invoicing and accounting platforms don't share a live database—when they're connected by API, CSV export, or worse, by hand—sync breaks are almost inevitable. They're small (₹2 per invoice) until they're not (₹2,000 by month three). And they're invisible until you reconcile. This playbook maps the seven sync breaks that trap most SMBs, shows you how to test your setup before go-live, and gives you a 90-minute audit to find the breaks you already have. Why separate invoicing and accounting tools diverge The root cause is simple: two systems, two databases, two truth sources. When you issue an invoice in your invoicing tool, you're creating a transaction in System A. When that transaction reaches your accounting tool (System B), it has to be translated —mapped to GL accounts, converted to your accounting currency, split by tax jurisdiction, assigned to a cost centre. Every step is a chance for the two systems to disagree. Here are the places they actually do: 1. Rounding on line-item tax Invoice has three line items at 18% GST: ₹1,000 + ₹180 tax = ₹1,180 ₹1,500 + ₹270 tax = ₹1,770 ₹1,333 + ₹239.94 tax = ₹1,572.94 Invoice total: ₹4,522.94. Your invoicing tool calculates tax per line and rounds to the nearest paise. Your accounting software might round at the invoice level, or use banker's rounding (round to nearest even), or round differently for display vs. GL entry. Result: ₹4,522.92 in QuickBooks. A ₹0.02 divergence per invoice compounds to ₹600/year in a 30-invoice-per-month business. 2. Foreign exchange conversion happens twice You invoice a US client ₹50,000 (USD equivalent: $600). Your invoicing tool records $600 at today's rate. Your accounting software receives that $600 entry but also receives the ₹50,000 amount from the invoicing tool's API and converts it again , using its own FX rate cache (which updates hourly, not in real-time). You now have two different USD-to-INR conversions in the same invoice. The GL shows $602. 3. Tax treatment splits by jurisdiction, but sync doesn't know locale You sell to Singapore (GST), Malaysia (SST), and Indonesia (PPN). Your invoicing tool tracks tax by line and jurisdiction. Your accounting software receives the invoice but doesn't know which jurisdiction it came from—the sync only sends invoice total, tax total, and maybe a GL account code. It posts the entire tax amount to a single "Sales Tax Payable" account instead of splitting it. Your tax liability report is now wrong, and your reconciliation audit reveals ₹15,000 sitting in the wrong account. 4. Discounts apply in invoicing but get lost in sync You issue a ₹50,000 invoice with a 10% early-payment discount (₹5,000). Your invoicing tool records the discount as a line item. Your accounting software's sync endpoint only pulls invoice total and tax; it doesn't know about the discount. It posts ₹50,000 to Revenue instead of ₹45,000. When the client pays ₹45,000, you have a ₹5,000 unexplained variance. 5. Multi-currency invoices post at the wrong rate You invoice ₹40,000 + $600. Your invoicing tool stores both amounts. Your accounting software's API integration only accepts one home-currency amount (₹50,000 INR equivalent). The sync runs, but the $600 line doesn't convert—it either disappears or converts at stale rates. The invoice in your GL is incomplete or wrong. 6. Credit notes don't reverse line items; they create new GL entries You issue Credit Note CN-001 to reverse a ₹10,000 invoice. Your invoicing tool marks the original invoice as linked to the credit note and shows net ₹40,000. Your accounting software receives the credit note as a separate transaction and posts it to a different GL account (Credit Note Issued, not a reversal of the original Revenue entry). You now have both the original invoice AND the credit note on the books, with no automatic link between them. Reconciliation is a mess. 7. Retainer + project + hourly on one invoice taxes differently One invoice, three revenue types, three tax rates (or three different tax treatments). Your invoicing tool calculates tax per line-item type. Your accounting software receives invoice total and total tax but has no way to split it back into the three GL accounts (Retainer Revenue, Project Revenue, Services Revenue) and their three corresponding tax liabilities. It posts the whole thing to one account, and your revenue forecast by type is now wrong. Why you won't notice until it's expensive Each of these breaks is small in isolation. A ₹2 rounding error per invoice is noise until you have 500 invoices outstandi