ERP Integration Company: What to Check Before You Hire One

An ERP integration company should do three things: copy your ERP data out safely, model it so every report uses one definition of each number, and prove the totals match your finance ledger. A proposal that skips any of the three produces dashboards that drift away from the ERP within a quarter.

The rest of this article covers how to judge each of the three, with a worked reconciliation you can reuse.

What does an ERP integration company actually deliver?

Not a dashboard. The dashboard is the last 20% of the work. The first 80% is a data layer: a staging area where ERP data lands on a schedule, a model with clean keys and agreed definitions, and a check that proves the numbers tie back to the ERP.

Ask what the deliverables are in that order. If the proposal starts with report screenshots and says little about staging, keys and reconciliation, you are buying visuals on top of an unmanaged extract.

Should it read the ERP database, its API or an export?

There are three ways to get data out. Each trades load on the ERP against freshness.

Some vendors restrict direct table access in the licence, so check the contract before anyone connects to production tables. For finance reporting, a scheduled extract into a staging database is the safest default: your ERP team keeps control and month-end close is never slowed by a report refresh.

What does a safe incremental load look like?

Reloading every invoice every night works until the table reaches millions of rows. The pattern that scales is a watermark: remember when the last successful load finished, and pull only what changed since.

-- Pull only rows changed since the last successful load
SELECT InvoiceID, CustomerID, InvoiceDate, NetAmount, TaxAmount, ModifiedAt
FROM   erp.SalesInvoice
WHERE  ModifiedAt > @LastLoadedAt
  AND  ModifiedAt <= @RunStartedAt;

Three details decide whether this is safe. Save the new watermark only after the load succeeds, so a failed run is retried instead of skipped. Cap the window at the run start time so rows written mid-load are picked up next time, not half-read. And plan for deletes: many ERPs flag a row as cancelled instead of removing it, and a periodic full comparison catches the ones that vanish.

How do you prove the numbers match the ledger?

With a reconciliation that runs after every load and lists every difference by name. This is the check I would ask any provider to show. Worked example, with made-up numbers, for one month:

The two invoices were posted after the load started, so they appear in the next run. Every rupee or dollar of the gap is explained, and the unexplained line is zero. If a provider cannot show a table like this for your data, you cannot tell a reporting error from a timing difference. Keep the table and the rule behind it: unexplained must be zero before a month is signed off.

What should the proposal include?

• The named source systems and, for each, the extraction method and why.
• A staging layer with keys, and a written field mapping from ERP fields to report measures.
• A monthly reconciliation to the ledger, with the tolerance stated.
• What happens when a load fails: who is told, and how fast data is restored.
• How ERP upgrades and custom fields are handled.
• Documentation and training at handover, and a support period after launch.
• Licensing, infrastructure and change requests priced separately from the build.

I deliver in stages: discovery, data layer, dashboard build, handover and 30 days of post-launch support. For SAP, Oracle and Dynamics sources, the ERP integration service page sets out the scope, and the SAP HANA to Power BI page covers the SAP side.

What is the short version?

Judge an ERP integration company by its data layer and its reconciliation, not its dashboards. Ask for the extraction method, the field mapping and a sample reconciliation before you sign.

Frequently asked questions

How long does an ERP integration take?

It depends on how many modules and how clean the data is, so any fixed number before discovery is a guess. A single finance module with a reconciliation is a smaller job than sales, inventory and purchasing together. Ask for stages, each ending in a deliverable you can check.

Do we need to buy new software?

Usually not. Power BI reads from a staging database or files, so the ERP stays as it is. You may need a gateway and a small database for staging. Licensing, infrastructure and change requests are priced separately, so ask for them as separate lines.

Which is hardest to integrate: SAP, Oracle or Dynamics?

None by default. The effort comes from custom fields, heavy customisation and years of configuration changes. A standard Dynamics finance module is simpler than a heavily customised SAP system, and the reverse also happens. Ask to see a sample of your own tables first.

Can ERP data refresh in real time?

For most finance reporting, daily or hourly refresh is enough and costs less. Near real time suits operations screens such as a production line, and it needs a different design. Decide per report instead of paying for real time everywhere.

What happens when the ERP is upgraded?

Table and field names can change. A documented field mapping and a reconciliation run after each upgrade catch breakage early. Keep the mapping in one place, so only that layer changes and every report keeps working.

Can a remote team do this work?

Yes. The work is secure access to a staging copy, modelling and reconciliation, all of which run remotely. Agree the access method and the hours you overlap at the start, and the project runs the same whether the team is in your city or not.