Services
CRM and ERP integration
When your CRM and your accounting system disagree, someone has to decide which one is true — usually by checking a third spreadsheet.
Integration is not a nice-to-have once a business has more than one system. Sales captures a customer in the CRM, finance creates them again in the accounting package, operations keeps a third list, and the three drift apart within weeks. The cost is not only re-typing; it is decisions made on numbers that do not match.
We build integrations that make one system the source of truth for each type of record, sync the rest from it, and handle the awkward cases — duplicates, partial records, records edited in two places at once — explicitly rather than leaving them for someone to discover at month-end.
Where it does not fit: if one system is about to be replaced, integrate after the replacement rather than building twice. If the two systems serve genuinely different purposes and only share a customer name, a nightly report may be cheaper than a live sync. We would rather scope a smaller, reliable link than a broad integration that fails quietly.
Signs this is worth fixing
- The same customer exists three times with different spellings
- Sales and finance report different revenue figures
- Stock or job status is only accurate in one person’s spreadsheet
- New customers are captured manually into the accounting system
- Nobody trusts the dashboard enough to use it
- Integration was attempted before and quietly abandoned
What we automate
Two-way sync with clear ownership
For each field we decide which system owns it and which systems follow. That single decision prevents most sync conflicts before they happen.
Deduplication and matching
Records are matched on stable identifiers where possible and fuzzy rules where not, with a review queue for anything ambiguous instead of silent merging.
Field mapping and transformation
Different systems name and format the same thing differently. We map, normalise and validate so a value means the same thing on both sides.
Error queues and replay
Failed syncs do not disappear. They land in a queue with the reason, and can be replayed once the cause is fixed.
Reporting across systems
Once the data agrees, a single reporting layer becomes possible — one place to answer "how are we doing" without exporting and stitching files.
How it works
- 01
Inventory systems and records
We list every system that holds customer, product, invoice or job data, and which records genuinely need to move between them.
- 02
Choose the source of truth
Per record type, we agree the system that owns it. This is the decision that makes the rest of the build straightforward.
- 03
Build, backfill and reconcile
We build the sync, run a historical backfill, and reconcile the result against both systems so the starting point is provably correct.
- 04
Monitor and hand over
Sync health is monitored, failures are surfaced, and your team gets a short guide to what to do when a record looks wrong.
What you get
- A system and record inventory
- A written source-of-truth matrix per field
- The working integration with two-way or one-way sync as agreed
- A historical backfill, reconciled against both systems
- An error queue with alerting
- Documentation of mappings and rules
Systems we work with
We integrate CRMs (HubSpot, Salesforce, Zoho, Pipedrive), accounting and ERP systems (Xero, Sage, QuickBooks, Odoo, SYSPRO), e-commerce platforms (Shopify, WooCommerce), and internal databases. Systems with a documented API are straightforward; for the rest we discuss what is realistically possible before quoting.
Questions people ask
Which system should be the source of truth?
Usually the one where the record is first created and most actively maintained — often the CRM for customers and the accounting system for invoices. The important thing is deciding per record type rather than leaving it ambiguous.
Can you fix a half-finished integration?
Often, yes. We start by documenting what exists and where it fails, then decide whether to repair or replace. Sometimes a smaller, more reliable rebuild is cheaper than untangling the original.
What about duplicates we already have?
We handle them as part of the backfill: match, propose merges, and get a human to confirm the ambiguous ones. Merging customer records automatically without review is how you lose history.
Do you use an off-the-shelf connector?
Where a native connector is genuinely reliable we use it. Where it is not — and many are not once fields or logic get specific — we build the integration directly, which is easier to debug and to change later.