← All services

Systems integration, including what happens when it fails.

ERP, finance, payroll, warehouse, scanners and third-party APIs, connected so data moves once and arrives right — with the slow, down and wrong cases designed in rather than discovered in production.

What we do

ERP and finance
Orders, inventory, invoices and journals moving between JD Edwards, Epicor LumberTrack, Dynamics 365, Workday or Planon and the systems around them, through supported interfaces.
APIs and events
REST services, webhooks, queues and scheduled jobs, with the contract written down and typed on both sides, so a change on either side fails a test rather than corrupting data.
Files and EDI
The flat files, CSV drops and EDI documents that still carry much of the work, made reliable: validated on arrival, acknowledged, and never processed twice.
Failure handling
Retries with backoff, duplicate protection, a holding queue for anything that cannot be processed, and an alert to a person instead of a silent gap.
Reconciliation
Scheduled checks that both sides agree — counts, totals, statuses — so drift is found within a day, not at month end.
Data migration
Moving from an old system to a new one: field mapping, transformation rules, validation, and reconciliation against the legacy system before cutover.

Three ways to start

Each starts by writing down the contract between the systems — the fields, the rules, and what happens when either side misbehaves.

Integration review

What already connects to what, where it fails, what nobody is watching, and what to fix first.

Integration map + risk list

Fixed fee

Single integration

One connection, specified — mapping, timing, failure cases — then built, tested and monitored.

Interface specification + build

Single fixed price

Integration programme

Several systems, a migration or a replatforming. The analysis comes first, because this is where integration projects go wrong.

FDD, then build

Fixed-fee analysis, then a fixed-price build

Where it usually hurts

If one of these sounds familiar, it is the kind of problem we are called in for.

  • Someone re-keys orders from one system into another every morning.
  • An interface fails quietly, and the gap is found at month end.
  • The same record exists in three systems with three different values, and nobody knows which is right.
  • A file is processed twice, and the invoices go out twice.
  • The integration was built by someone who has left, and nobody knows what it does when the other side is down.

Where this experience comes from

Our lead analyst's career history, described by sector — not an Elarion client list. More on the About page.

  • ERP integrations specified with demand-planning and transportation-management systems at a forest products company and a food manufacturer, including the move from JD Edwards World to EnterpriseOne.
  • API endpoint validation and integration testing across ERP, reporting, finance, handheld scanners, warehouse, work orders and web applications at a multi-mill forest products company.
  • Asset and master data synchronised between an HR platform and a facilities and asset management system at a university, with testing across both.
  • A payroll and reporting migration at a transit authority: data mapping, transformation and validation rules, and reconciliation against the legacy system before it was retired.

Integrations in practice.

CrewDispatchr, built for a client, hands dispatch data to payroll and billing. The systems pages cover the ERPs we integrate with most.

Questions buyers ask

Do we need middleware or an integration platform?
Sometimes. For a handful of connections, direct integrations with proper failure handling are cheaper to run. Past a certain number of systems, a platform pays for itself. The integration review says which side of that line you are on.
Can you integrate with a system that has no API?
Usually. Files, database views, EDI and scheduled exports, chosen for reliability first and documented so the next person understands them.
What happens when one side changes?
Every integration is built against a written contract and covered by tests, so a change on either side shows up as a failing check and an alert rather than as bad data in production.
Our ERP feels too rigid. Should we replace it?
Usually not. The rigidity is often what keeps the financial record trustworthy. The better move is usually to build what the business needs beside the ERP and integrate it properly, so the ERP stays the record and upgrades stay simple.
Do you work with our ERP partner?
Yes. Most integration work sits outside the ERP core and does not need to wait for them; anything that touches their configuration is coordinated with them.
How is it priced?
As a fixed price against a written interface specification. Where several systems or a migration are involved, that specification is produced first, in a fixed-fee analysis phase.

Further reading

Related services

Systems that should be talking to each other?

30 minutes, free. Bring the problem, or the change you already have in mind.

Book a discovery call