Pricing
Log inBook a demo

Platform · data

One model, not six systems and a nightly sync

An integration moves data between two systems that each hold their own idea of what a customer is. A shared model means there is only one. That distinction sounds academic until you try to explain why the pipeline report and the AR ageing disagree about your largest account.

Map your stackIntegration services

Where do your systems disagree?

Connect two systems read-only and we will show you every place they hold different answers to the same question.

1 / 3
Entity resolution firstRead-only to startSurvives an ERP change
QuickBooksQuickBooks190NetSuiteNetSuite190StripeStripe190RampRamp190GustoGusto190ShopifyShopify190SalesforceSalesforce190PlaidPlaid190Business graphone model, all systemsDepartment P&LEntity roll-upProject marginShadow ledgerAgent contextUniversal search
The objectsWhy it mattersQuestions

The objects

Six families, one identity each.

Parties

Customer, vendor, employee, contact, and partner as one resolved identity each, deduplicated across every connected system on tax ID, domain, remit-to, and history.

Agreements

Contracts, quotes, purchase orders, subcontracts, and change orders — with terms that drive revenue recognition and billing rather than being re-keyed into them.

Obligations

Invoices, bills, credit memos, and payments, each linked to the agreement that created it and the journal entry it produced.

Work

Projects, phases, tasks, tickets, and time — where the labour cost that determines margin actually originates.

Dimensions

Entity, department, location, class, and project carried on every journal line rather than approximated at reporting time.

Events

Every human and agent action against every object, in one append-only log with the same schema.

Entity resolution is the whole engagement

Connectors are a commodity. Every integration platform can move a record from Salesforce to QuickBooks. What none of them resolve is that Salesforce has Northwind Trading Co., your ledger has Northwind Trading Company plus a stray Northwind (do not use) from 2023, and your payroll system knows a department called Delivery that the ledger calls Operations.

A sync matching on name creates a third record and makes the problem permanent. So the first two weeks of any integration engagement are spent on entity resolution and dimension mapping — matching on tax ID, domain, remit-to, and transaction history, and handing you the genuinely ambiguous ones to decide.

That is decision work rather than configuration work, which is why most integration projects skip it: it requires your team, not just ours. It is also the entire difference between reporting you trust and reporting somebody reconciles monthly.

An integration moves data between two truths. A shared model means there is only one.

What a shared model unlocks

  • Dimensional reporting without a rebuild. Department, location, entity, and project P&L as a query rather than a monthly spreadsheet exercise.
  • Agents with real context. An AP agent that can see the contract, the PO, the budget, and payment history behaves sensibly. One that sees only the invoice does not.
  • Cross-function facts. Sales sees credit risk; finance sees weighted pipeline; delivery sees the vendor bill that just landed against their project.
  • Revenue recognition from source. Contract terms captured once, at signature, by the person who negotiated them.
  • One audit trail. Human and agent actions against every object in one schema, which is what makes the trail answerable rather than a join across five logs.

It survives a system change

The graph is not tied to any particular ledger. If you move from QuickBooks to Sage Intacct — or to us, or away from us — you repoint the accounting connector and everything built on top keeps working: the reporting, the agents, the portal, the custom modules.

That is a genuinely good reason to build this layer before choosing a new ERP rather than after. It also means the switching cost we impose on you is lower than the one most vendors do, which we would rather state plainly than have you discover.

Read-only by default

Every connection starts read-only and most stay that way. Write-back is enabled per integration and per object as a separate, revocable permission — nothing we install can alter your books unless you switch that on deliberately.

Questions

What people ask.

Is this a data warehouse?
No. A warehouse is optimised for analysis over historical copies. This is an operational model that agents and workflows act on in real time, and it feeds your warehouse rather than replacing it.
What happens when two systems genuinely disagree?
A precedence rule you configure per object and field decides which system is authoritative, and the disagreement is logged rather than silently resolved. Where no rule fits, it goes to a person.
Do we have to move data out of our systems?
No. The graph reads and holds a resolved model; your systems remain the systems of record until and unless you decide otherwise.
How long does entity resolution take?
Usually a working session or two with your controller in the first fortnight. The ambiguous matches are the ones that need a human decision, and there are fewer than people expect — typically a few dozen.
Can we query it directly?
Yes, through the REST API, the MCP server, or a scheduled export into your warehouse. It is your data and the access paths are documented.

See where your systems disagree.

Two read-only connections is enough to produce the list, usually within a week.

Get a free assessmentIntegration services