You're three days into month-end close. The revenue ledger in your accounting software doesn't match the deals marked 'won' in your CRM. The finance team is asking questions. The CRM team swears the numbers were right when they hit send. Nobody is wrong—they're just looking at different calculations. This happens at every company that uses separate CRM and accounting tools. The root cause isn't sloppy data entry or missing integrations. It's that CRMs and accounting software solve different problems, and they make different mathematical choices when they shouldn't have to. Why the numbers diverge: Four hidden calculation gaps When an invoice moves from your CRM to your accounting software, it passes through at least four separate places where the total can change. Most of these changes are invisible unless you know to look. 1. Tax calculation timing and precision Your CRM calculates tax on the subtotal. Your accounting software recalculates it on the invoice total. Or one rounds at each line item; the other rounds once at the end. Example: A ₹50,000 subtotal with 18% IGST. CRM method: 50,000 × 0.18 = 9,000. Total = ₹59,000. Accounting method: 50,000 × 0.18 = 9,000.00 (with bank decimal precision) = ₹59,000.00. Seems identical. But if your CRM applies tax to each line separately—and one line is ₹33,333.33—rounding happens at line level, not invoice level. The total shifts by a few paise per line. Across 20 invoices, that's hundreds of rupees in unexplained drift. 2. Multi-currency conversion and mid-stream rounding If you invoice in USD but your ledger is in INR, both systems apply exchange rates. They use different rates (one uses the API rate from 2 PM, the other from 3 PM). One rounds the conversion; the other rounds the final amount. The difference is small per invoice but compounds monthly. The same issue happens if you offer discounts in percentages and your CRM rounds before tax, while your accounting software applies tax to the discounted amount. 3. Discount timing and scope A 10% early-payment discount can be applied three ways: Before tax is calculated (lower tax base). After tax is calculated (higher final discount, lower revenue). As a separate line item (accounting sees it, CRM might not sync it cleanly). Your CRM might apply it before tax. Your accounting software might interpret the sync as a post-tax discount. The invoice total changes by 1–3%, depending on your tax rate. 4. Payment allocation and partial invoice logic When a customer makes a partial payment against an invoice, your CRM might show the invoice as 'partially paid' and still count the full amount as revenue. Your accounting software allocates the payment and adjusts the receivable. If the payment doesn't match the invoice total (overpayment, underpayment, or a late fee added), the two systems disagree on what 'the invoice amount' even means. The worst reconciliation drift happens not at invoice creation, but when payments arrive and discount adjustments are applied after the fact. By then, the invoice is already in two separate ledgers. Real audit: Orin + Xero vs. Pipedrive + QuickBooks Online Let's walk through a realistic scenario across two common stacks. Setup Invoice created: ₹1,00,000 subtotal, 18% tax, 5% early-pay discount if paid within 7 days. Customer pays ₹99,000 on day 5 (claiming the discount but underpaying by ₹4,100). Orin + Xero stack Orin's invoicing applies discount before tax. When synced to Xero: Subtotal: ₹95,000 (after 5% discount) Tax: ₹17,100 (18% on ₹95,000) Invoice total: ₹1,12,100 Payment logged: ₹99,000 (user applies full discount, then underpays) Xero sees: Invoice ₹1,12,100, payment ₹99,000, AR balance ₹13,100 Orin's CRM still shows the 'won deal' as ₹1,12,100 because that's the invoice total. Both systems agree. Pipedrive + QuickBooks Online stack Pipedrive applies discount after tax (as a line item). When synced to QuickBooks: Subtotal: ₹1,00,000 Tax: ₹18,000 (18% on full amount) Subtotal with tax: ₹1,18,000 Discount applied: ₹5,900 (5% of the taxed total) Invoice total: ₹1,12,100 Payment logged: ₹99,000 QuickBooks sees: Invoice ₹1,12,100, payment ₹99,000, AR balance ₹13,100 Again, both agree—but for different reasons. The discount landed in a different place, yet the final number matched. Where they'd diverge: If Pipedrive syncs the discount as a separate item and QuickBooks doesn't recognize it as tax-reducing, the tax amount recalculates. Now Pipedrive thinks the invoice is ₹1,12,100, but QuickBooks thinks it's ₹1,13,800 (because it recalculated tax on the full ₹1,00,000). The payment allocation breaks entirely. The reconciliation playbook for month-end close Rather than fix the systems, build a monthly audit process that catches and explains these gaps before they block your close. Step 1: Pull both totals (Day 1 of close) Export invoices from your CRM for the month. Export the same invoices from your accounting software. Sort by invoice number. You need three columns: Invoice ID CRM total Ac