Most ERP CRM integration problems in Singapore mid-market companies are not outages. They are quiet: the same customer exists twice, a CRM quote does not match the tax invoice, a closed deal never becomes a sales order, or a sync job drops records and tells nobody. Each failure has a first symptom that someone in sales or finance notices long before IT does. Catch it by symptom, fix it at the root cause, and give every failure mode a named owner.
Educational only; not tax, legal or accounting advice. Confirm GST and PDPA obligations for your own business with your tax adviser and data protection officer.
Who this is for, and who should skip it
For: finance controllers, sales operations leads, IT managers and integration owners at Singapore mid-market companies that run a CRM for sales, an ERP or accounting system for finance, and a sync between them that “mostly works”, often billing in SGD and at least one foreign currency.
Skip if: you have not built the integration yet (start with master data before you integrate); you are planning an ERP version upgrade (see systems integration that survives ERP upgrades); or your main question is e-invoicing (see InvoiceNow-ready integrations). This article does one job: diagnose an ERP–CRM sync that is already live and misbehaving.
Why ERP–CRM sync fails quietly
A CRM makes selling easy: anyone can create an account, edit an address or clone a quote. An ERP keeps the books correct: customers, prices, tax codes and invoices are controlled. An integration joins a permissive system to a strict one. Where they disagree, it either rejects the record and logs the error somewhere nobody reads, or accepts it and spreads the problem. That is why IT is rarely first to notice.
The Singapore details that trip integrations
A few local rules turn small mapping choices into real problems. Check these against your field mapping:
- GST rate and calculation method. The current GST rate is 9%. IRAS allows two ways to compute GST on a multi-line tax invoice, per line then summed, or on the invoice subtotal, and says the totals can differ through rounding, so the chosen method must be applied consistently. If CRM quotes use one method and the ERP invoices with the other, cent differences are guaranteed.
- Foreign-currency invoices. On the same IRAS page: when you invoice in a foreign currency, the totals excluding GST, including GST and the GST payable must be converted to Singapore dollars on the tax invoice, using approved exchange rates for GST purposes. A static rate typed into a CRM quote is not that.
- GST-inclusive quotes to the public. GST-registered businesses must display and quote GST-inclusive prices to the public, including written quotes. If your CRM produces quotes for individual customers, a “$100 + GST” template is a compliance issue, not just a formatting one.
- UEN is not always the GST number. The Unique Entity Number (UEN) is the standard identifier for Singapore entities, which makes it a strong matching key between CRM accounts and ERP customers. But IRAS notes that a business’s UEN and GST registration number can be different. One generic “tax ID” field holding either value causes wrong numbers on invoices and failed matches.
- Five-year records. IRAS says tax invoices must be kept for at least five years, so a CRM merge that triggers a hard delete in the ERP is a records problem, not a tidy-up.
- InvoiceNow. GST-registered businesses must submit invoice data to IRAS through InvoiceNow-Ready Solutions, rolled out in phases. A wrong customer or tax code from CRM then travels with the invoice data.
- Personal data accuracy. Section 23 of the Personal Data Protection Act asks organisations to make a reasonable effort to keep personal data accurate and complete where it is likely to be used for a decision affecting the person or disclosed to another organisation. A sync that reverts a corrected contact email works against that.
The ERP–CRM failure-mode matrix
Ten failure modes, each starting from the symptom a business user sees. Use it in a one-hour session with finance, sales ops and whoever maintains the integration, marking each row “seen”, “not seen” or “don’t know”. “Don’t know” usually means no detection exists.
| # | Failure mode | First symptom (who sees it) | Usual root cause | Early detection | Fix | Owner |
|---|---|---|---|---|---|---|
| 1 | Duplicate customers | Same company twice in AR ageing; payment applied to the wrong one (credit control) | CRM creates an account per deal; no shared key between systems | Daily count of ERP customers with no CRM ID, and the reverse; match on UEN | UEN as matching key, cross-reference IDs stored on both sides, block creation without UEN for Singapore entities | Customer data steward |
| 2 | Wrong tax identifier | Customer’s GST number wrong or missing on invoice (customer, finance) | One “tax ID” field used for both UEN and GST number | Format validation on each field; sample invoices monthly | Separate UEN and GST registration fields; ERP owns the GST field | Finance systems |
| 3 | Quote and invoice totals differ | Customer disputes cent-level differences (sales, AR) | CRM and ERP compute GST with different methods or rounding | Compare quote total with invoice total for every converted deal | One system calculates tax; the other only displays the result | Finance systems |
| 4 | Foreign-currency mismatch | USD deal invoiced without correct SGD amounts, or at a different rate (finance) | CRM stores a fixed rate typed at quote time | Flag invoices where currency is not SGD and SGD totals are missing | ERP owns conversion using approved rates; CRM shows indicative SGD only | Finance |
| 5 | Silently dropped orders | Deal marked won, no sales order in ERP (account manager) | ERP validation rejects the record; error sits in a log | Daily reconciliation: won deals vs orders created, by CRM opportunity ID | Failed records go to a visible exception queue with an alert and a retry button | Integration owner |
| 6 | Duplicate orders | Two sales orders for one deal (warehouse, finance) | Retries after timeouts with no idempotency key | Unique constraint on CRM opportunity ID in the ERP order | Idempotent create calls (see idempotency and retry design) | Integration developer |
| 7 | Ping-pong overwrites | Address or contact keeps reverting after correction (sales, customer) | Two-way sync with last-write-wins and no field ownership | Audit log shows the integration user changing the same field back and forth | Field ownership map: one system of record per field, one-way flow for each | Solution architect |
| 8 | Stale credit status | Sales closes a deal for a customer on credit hold (credit control) | AR status pushed to CRM in a weekly batch, or not at all | Compare ERP credit-hold list with CRM flags daily | Push credit-hold changes as events; block quote approval when on hold | Finance with sales ops |
| 9 | Price and product drift | Discontinued item or old price quoted (customer, sales) | Catalogue loaded once at go-live, then edited in both places | Weekly diff of active items and list prices across systems | ERP owns items and prices with effective dates; scheduled sync to CRM | Pricing owner |
| 10 | Merges that orphan history | Invoices vanish from the CRM account view after a merge (account manager) | CRM merge deletes the losing record; ERP still points to it | Count ERP customers linked to CRM IDs that no longer exist | Merges send a survivor ID; ERP records are re-linked, never hard-deleted | Customer data steward |
Two patterns are common. Rows 1, 7 and 10 often share one cause: nobody decided which system owns the customer record. Rows 3 and 4 usually trace back to tax being calculated in two places.
Three checks to run this week
You do not need a monitoring platform to start. These checks run on exports or simple queries:
- Won-deal reconciliation (rows 5 and 6). Yesterday’s won opportunities in CRM against sales orders created in the ERP, matched by CRM opportunity ID. Anything missing or doubled goes to the integration owner by noon.
- Orphan and duplicate customer count (rows 1 and 10). ERP customers with no valid CRM ID, CRM accounts flagged as customers with no ERP ID, and any UEN appearing on more than one active record. Track the count weekly; it should fall, not drift.
- Quote-to-invoice variance (rows 3 and 4). For every invoice raised from a CRM quote, compare totals and currency. Any variance, even one cent, gets a reason code.
Agree who receives each check and what they do with it. A report nobody owns is just another log.
Worked example (illustrative)
This is a constructed example to show the method, not a client case.
A Singapore B2B distributor runs a cloud CRM for sales and a mid-market ERP for finance. The go-live vendor built the sync and nobody has owned it since. In one month credit control raises three complaints: a customer chased for a paid invoice, a deal sold to a customer on credit hold, and a one-cent quote dispute.
Using the matrix, the team marks rows 1, 3 and 8 “seen” and rows 5, 6 and 10 “don’t know”. A won-deal reconciliation for the previous month finds orders that never reached the ERP because payment terms were blank in CRM. The customer count finds the paying customer stored twice, once under an old trading name, with the payment applied to the inactive record.
The fixes are unglamorous: UEN mandatory for Singapore accounts and used as the match key; payment terms required before a deal can be won; GST calculation removed from the CRM quote template; credit-hold changes pushed to CRM as they happen. Finance owns rows 2 to 4 and 8, sales ops takes the data steward role, and the support partner owns the exception queue under its application management scope.
Common mistakes when fixing a live integration
- Trusting a green dashboard. “All jobs succeeded” only means jobs ran, not that records arrived intact. Reconcile business counts, not job counts.
- Fixing data by hand in one system. Correcting an address in the ERP while the CRM still owns that field means the next sync puts the error back. Fix at the system of record, then let it flow.
- Two-way sync on everything. It feels complete but multiplies conflicts. Most fields should flow one way.
- Calculating tax in the CRM. Quotes must show tax, not compute it independently. Let the ERP calculate and the CRM display.
- Testing with clean data. Failures come from real records: old trading names, foreign customers with no UEN, blank fields. Test fixes against a copy of production-like data, as covered in contract testing for ERP APIs.
Decision framework: fix now, fix this quarter, or redesign
Once the matrix is filled in, sort each “seen” row with four questions, in order:
- Does it change an amount, tax figure or identifier on a tax invoice? Fix now. Finance owns it.
- Does it create or lose a business record (order, customer, invoice)? Fix now. The integration owner owns it.
- Does it lead people to a wrong decision (credit, pricing, stock)? Fix this quarter, with a manual check until then.
- Is it a delay or cosmetic difference? Backlog, but add detection so you know if it grows.
Then step back. If four or more rows are “seen” and there is no written field ownership map, patching rows one by one never ends. Redesign instead: name the system of record per object and field, choose sync, event or batch per flow, and rebuild the riskiest flow first. If only one or two rows are “seen” and detection exists, targeted fixes are the better use of budget.
FAQ
Should the CRM or the ERP own the customer record?
Usually split by field. Commercial and contact details (owner, segment, contacts) sit well in the CRM. Legal name, UEN, GST registration, billing address, payment terms and credit status belong in the ERP, because they end up on invoices and in the books. The important part is writing the split down.
Do we need real-time sync?
Not for everything. Credit holds and won deals benefit from near real-time flow because people act on them at once. Catalogues and invoice history are often fine on a schedule. Choose per flow.
Does InvoiceNow change our ERP–CRM integration?
It mainly affects the ERP’s invoicing output, but it raises the cost of bad CRM data: a wrong customer, UEN or tax code reaches IRAS with the invoice data. Check your implementation date with IRAS and clean rows 1 to 4 first.
Can we fix this without replacing either system?
Usually, yes. These failure modes are about ownership, keys and detection, not the products. Replacing software without fixing ownership tends to recreate the same problems.
What to do next
Print the matrix, book one hour with finance, sales ops and the sync’s maintainer, and mark every row. Run the three checks for a week before deciding anything. If you want a second pair of hands to run that session or rebuild the flows that keep breaking, see how we approach ERP CRM integration in Singapore or broader systems integration, and get in touch.