Your CRM shows an invoice for ₹47,500. Your GL posts ₹47,489. Your team spends three hours hunting the discrepancy. You find a rounding error in the tax split. Next month, it happens again—this time currency conversion. The month after: line-item timing. Invoice data moves through at least four systems: CRM (where the deal closes), invoicing software (where the document renders), payment gateway (where it gets paid), and accounting (where it settles). Each handoff is a breakpoint. Rounding, currency conversion, tax proration, timing windows, multi-currency splits, and line-item sequencing can all cause totals to diverge. This playbook maps nine common sync breaks, shows you how to audit them in 90 minutes, and walks you through the one automation that prevents them from happening again. Breakpoint 1: CRM line-item total vs. invoicing system calculation Your CRM line items sum to ₹42,857. Your invoicing system renders the invoice at ₹42,862. The difference is usually rounding—each line item rounds at the unit level, then the total rounds again. The math: If you have three line items at ₹14,285.67 each, the CRM might show 14,286 × 3 = 42,858, but your invoicing system may round each line (14,286 + 14,286 + 14,285 = 42,857) or round the total last (42,857.01 → 42,857). The one-rupee difference is invisible until it reaches the GL. How to audit: Pull your last 50 invoices. For each, export the CRM line items and the rendered invoice PDF side by side. Sum the CRM total and the PDF total. Use a spreadsheet formula to flag any variance. Most invoicing software allows you to specify rounding rules—round at line level, round at total level, or round to nearest paisa—so consistency is a choice, not an accident. Breakpoint 2: Tax calculation and line-item proration You invoice ₹40,000 + 18% GST. The CRM calculates tax as ₹7,200, total ₹47,200. But if the invoice splits across two line items—₹25,000 and ₹15,000—and the invoicing system prorates tax to each line, rounding at line level can shift the total by ₹1–₹3. The math: Line 1: ₹25,000 + (₹25,000 × 0.18) = ₹29,500. Line 2: ₹15,000 + (₹15,000 × 0.18) = ₹17,700. Total: ₹47,200. Matches. But if your invoicing system rounds line-item tax independently (line 1 tax rounds to ₹4,500, line 2 tax to ₹2,701), the total becomes ₹47,201. The GL receives ₹47,201; the CRM recorded ₹47,200. How to audit: For invoices with multiple line items, manually recalculate tax at line level. Compare the pro-rated total to the invoice total. If you use Orin's invoicing module or another automated system, check the tax rounding setting in configuration—most platforms let you choose: round at line level or round total only. Breakpoint 3: Multi-currency conversion and timing You invoice a Singapore client for SGD 700 on the 15th. The CRM converts it to ₹43,050 (rate: 61.5). The invoice is paid on the 18th; your payment gateway converts it at 61.2, posting ₹42,840 to your bank. Your GL records the payment as ₹42,840 but the invoice as ₹43,050. A ₹210 unrealized FX loss sits in suspense until quarter-end. The math: CRM invoice date uses one spot rate. Payment date uses another. Your GL may use a third (the month-end average rate). Three rates, three totals. How to audit: Pull all multi-currency invoices from the past 90 days. For each, record three rates: (1) the rate used in the CRM when the invoice was created, (2) the rate used by your payment gateway when it was paid, and (3) the rate used by your GL. Calculate the realized and unrealized FX variance. Most teams find 0.5–2% divergence per invoice. Over 100 invoices, this becomes material. Orin's accounting integration can sync invoices and auto-post currency variance to a designated GL account, removing manual reconciliation. Breakpoint 4: Timing windows—invoice date, due date, payment date An invoice is created on the 10th (CRM records it). It's sent on the 11th (invoicing system renders it and emails it). It's paid on the 15th (payment gateway receives funds). Your GL receives the payment posting on the 16th. Four dates, and each system treats a different one as the "invoice date." If the CRM uses invoice date and the GL uses payment date, the invoice sits in AR for days before it matches. How to audit: For your last 20 invoices, list (1) created date in CRM, (2) sent date in invoicing system, (3) payment received date in payment gateway, (4) GL posting date. Calculate the median lag. Most teams see 3–7 days between CRM and GL. Breakpoint 5: Partial payments and payment allocation You invoice ₹50,000. The client pays ₹40,000 on day 1 and ₹10,000 on day 5. Your CRM shows two payment records, each linked to the same invoice. Your invoicing system shows the invoice as partially paid. Your GL receives two separate payment postings. If your payment gateway and GL use different matching logic, one might post both payments against one invoice; the other might split them. Or the first payment posts, but the system doesn't know which invoice to mat