Your sales team marks a deal Won in the CRM on the 28th. Accounting closes the month on the 30th. By November 5th, your controller is on Slack asking why the GL doesn't match the pipeline. This pattern repeats every close because the CRM and accounting live in separate worlds—and the handoff between them has nine distinct failure modes. We've worked through dozens of month-end audits across Southeast Asian SMBs. Every single one had revenue recognition gaps that looked random until we mapped the actual integration points. Here are the nine breaks that hide until they matter. 1. Deal-stage timestamp vs. revenue recognition date Your CRM records deal closure at the moment a rep clicks Won . Your accounting system needs the invoice date or service delivery date for revenue recognition under accrual accounting (or cash accounting if that's your regime). The gap: if a deal closes on the 28th but the invoice isn't issued until the 2nd, which date controls? Most CRM-accounting integrations assume the deal-close date is the revenue date. It isn't always. What breaks: Deals marked Won in December don't actually invoice until January, but they're in your December revenue Multi-invoice deals (deposit + completion) get synced as a single revenue event Service-based deals with start dates in the future get recognized immediately instead of on service commencement The fix: Create a separate revenue recognition date field in your CRM, distinct from the deal-close date. Sync that field to accounting, not the close date. For subscription or multi-stage deals, use a custom automation to set the revenue date to invoice send date or service start date. 2. Multi-currency rounding and exchange-rate lock timing A SGD 50,000 deal closes. Your CRM records it in SGD. Accounting needs it in your home currency (MYR, IDR, PHP, whatever your GL runs in). The exchange rate at deal close is 3.05. By month-end, it's 3.08. Most integrations apply the rate at sync time, not at deal-close time. So a SGD 50,000 deal becomes MYR 154,000 in the CRM but MYR 154,000 in the GL—except accounting recalculates at the month-end rate and gets MYR 154,400. A 400 MYR rounding error per deal compounds across 30–40 monthly closes. What breaks: Rounding errors accumulate in a sub-ledger no one reconciles until year-end Monthly currency variance reports show noise instead of real FX exposure Deal-level margins look wrong because the cost side used a different rate than the revenue side The fix: Lock the exchange rate in your CRM at deal-close time. Store both the SGD amount and the MYR equivalent in your CRM record before sync. Accounting consumes the MYR value, never recalculates. This removes the rate-timing gap entirely. 3. GL account selection: CRM product type vs. accounting's chart of accounts Your CRM has four product types: software licenses, implementation, support, consulting. Accounting has 12 GL accounts: recurring revenue, one-time services, partner pass-through, third-party implementation, etc. The integration tries to map CRM product type to GL account. But the mapping assumes every software license is the same GL account. In reality, some are annual, some are monthly; some have refund obligations, some don't. What breaks: All four product types map to a single GL account by default, hiding revenue streams that need separate reporting A deal that's 60% consulting and 40% software gets shoved into one account Mapping changes (product code 101 moves from Recurring to Partner revenue ) require manual GL journal entries to restate prior months The fix: Use a GL account code field in your CRM product master, not a generic category. Require your sales team to log deal line items with a GL code at entry time. The integration consumes that code directly, no mapping table needed. Bonus: your reps see which GL codes are active, which reduces upstream confusion. 4. Tax rate mismatches and jurisdiction-specific rules A deal closes with a 6% tax rate coded in the CRM. Accounting runs in Malaysia, where services are 0% SST and goods are 6%. The deal is mixed: software (0% SST as a service), hosting (6% SST as goods). Your CRM picked 6% because that's the default. Accounting didn't reconcile it. By month-end, tax liability is overstated by the 6% applied to the service portion. In Indonesia or Philippines, GST/PPN rules differ further, and different GL accounts are used for tax input vs. output. What breaks: Tax liability overstates or understates every month Quarterly tax returns don't reconcile to GL because the GL record is wrong Cross-border deals (deliver to SG customer but invoice from MY entity) use wrong tax regime entirely The fix: Bind tax rate to invoice line item, not deal header. Use native invoicing that knows your tax regime rather than syncing tax rate from the CRM. If you must sync, create a tax regime lookup (SST, GST, PPN, VAT) and let accounting override it at invoice time. Never let a deal's tax rate auto-populate GL—make it explicit. 5.