Integration

Data entered once, and reconciled without anybody watching

Almost every business we meet has someone whose morning starts by moving data between two systems by hand. It is slow, it is where the errors come from, and it is usually the cheapest thing on the list to fix properly.

Book a Consultation

Ask a question first

Service Layer, DI API and B1if
Failure handling designed in, not assumed
Reconciliation you can actually check

The situation

Where integrations go wrong

The difficulty in an integration is almost never the happy path. It is what happens on the day something is unavailable, duplicated or malformed.

It is a person, not an interface

Somebody exports a file from one system every morning and imports it into another. It works until they are on leave.

Failures are silent

The interface stops and nobody finds out until a customer asks where their order is, because nothing was built to notice.

Retries create duplicates

A timeout is retried, the original had already succeeded, and now there are two orders. Nobody designed for the message arriving twice.

Nothing reconciles

There is no way to answer the question everybody eventually asks: are the two systems actually saying the same thing today?

It bypasses business logic

Data is written straight into SAP tables, so stock does not update, the ledger does not post, and the numbers drift apart.

The other system changed

An API version was deprecated or a field was renamed, and the interface has been failing quietly for three weeks.

How we build them

We design for the bad day, not the demonstration

Any developer can move a record between two systems when everything is working. What you are paying for is the behaviour when it is not.

Every interface we build goes through SAP Business One business logic, using the Service Layer or the DI API rather than writing to tables directly. That matters because posting a sales order is not an insert — it affects stock, commitments, pricing and the ledger. An integration that bypasses that logic will appear to work and will quietly corrupt your numbers.

The design work is mostly about failure. What happens when the other system is unavailable, when a message arrives twice, when a field is missing, when a customer record does not exist yet, when a value fails validation. We agree the answer to each of those before building: what retries, what queues, what alerts a human, and what is safe to discard. Every interface gets monitoring and an exception route, because an integration nobody is told about when it breaks is worse than a manual process somebody is doing deliberately.

And every interface gets a reconciliation. There is always a way to ask whether the two systems agree — counts, totals, or a comparison report — and it is available to your team rather than only to us. That is what turns an integration from something you trust into something you can verify.

Every interface we build has

An agreed behaviour for each failure case
Monitoring and an alert when it stops
An exception queue a person can work
A reconciliation your team can run

What we connect

The integrations that come up most

E-commerce and marketplaces

Orders, customers, stock levels and pricing between SAP Business One and your web shop or marketplace channels, in both directions.

Warehouse and logistics

Picking, despatch, goods receipts and carrier integration, including handheld and scanning systems that need real stock positions.

CRM and sales tools

Customers, contacts, quotations and order status shared between SAP Business One and the system your sales team actually uses.

Payments and banking

Payment gateway settlements, bank statement import and automated allocation, so cash matching stops being a manual exercise.

Third-party and bespoke systems

Industry systems, supplier and customer EDI, portals and internal applications, connected through the Service Layer with proper authentication.

Monitoring and reconciliation

Failure alerting, an exception queue your team can work, and reconciliation reporting that proves the two systems agree.

How it works

How an interface gets built

Map

What data moves, in which direction, how often, and which system is authoritative for each field. Most integration problems are actually unresolved ownership questions.

Field-level mapping
System of record agreed
Volume and frequency

Design failure

Every failure case gets an agreed behaviour before any code is written: unavailable, duplicated, malformed, rejected, out of sequence.

Retry and idempotency rules
Exception routing
Alerting thresholds

Build

Built against the Service Layer, DI API or B1if as appropriate, under source control, in a test environment connected to a test instance of the other system.

Supported interfaces only
Test environment both ends
Source controlled

Test

Including the awkward cases: the other system offline, a duplicate message, a rejected record, and a realistic day of volume rather than three sample records.

Failure simulation
Volume testing
Duplicate handling verified

Reconcile

A reconciliation report built and handed to your team, so anyone can answer whether the systems currently agree.

Reconciliation report
Run by your team
Discrepancy investigation route

Run

Monitored in live use, with alerts to a named person and a documented route for reprocessing anything that failed.

Live monitoring
Failure alerts
Reprocessing procedure

Technical detail

How we connect things

SAP Business One interfaces

Service Layer (OData) for most integrations
DI API where client-side logic is needed
Integration framework (B1if) scenarios
User-defined fields for external identifiers
Never direct writes to SAP tables

Transport and protocol

REST and JSON, SOAP where required
Scheduled batch and event-driven patterns
Webhooks and polling
SFTP and file-based interfaces where unavoidable
EDI message handling

Reliability

Idempotency keys to prevent duplicates
Retry with backoff for transient failures
Dead-letter queue for messages needing a human
Sequence handling where order matters
Replay of failed messages after a fix

Security

Credentials in environment configuration, never in code
Least-privilege service accounts
Transport encryption end to end
Audit logging of what moved and when
Personal data minimised in transit

Observability

Interface health monitoring
Alerting to a named person on failure
Message-level logging with correlation
Volume and latency trends
Exception queue with a working procedure

Reconciliation

Count and value comparison reporting
Unmatched record identification
Period-end reconciliation to the ledger
Reports your team can run without us

What changes

What a properly built interface is worth

The morning re-keying stops

The hour somebody spends moving data between systems disappears, along with the transcription errors that came with it.

Failures are noticed immediately

An alert to a named person the moment something stops, rather than a customer telling you three days later.

Duplicates stop happening

Idempotent design means a retried message does not become a second order, which is the most common integration defect we are called in to fix.

You can prove it agrees

A reconciliation your own team runs, so the two systems agreeing is a verified fact rather than an assumption.

Stock and ledger stay correct

Data posted through SAP business logic, so inventory, commitments and the ledger update the way they are supposed to.

What to expect

The shape of an integration project

Simple, well-documented API

Two to four weeks per interface where the other system has a good API and clear documentation.

Poorly documented or legacy system

Four to eight weeks or more. Time goes into discovering how the other system behaves, not into the SAP Business One side.

Bidirectional with conflict handling

Longer again. When both systems can change the same record, the rules for who wins have to be designed and agreed.

The main dependency

The other system, and access to a test instance of it. Integration projects usually wait on that rather than on development.

Ongoing

Interfaces need monitoring and occasional change when the connected system changes. This is covered under support.

We will always ask whether the integration is necessary. Sometimes the better answer is to stop using the second system, and we would rather say that than build an interface to preserve it.

Fit

Whether this is the right conversation

A good fit if

Somebody re-keys data between systems as part of their daily routine
Your web shop and your ERP disagree about stock
An existing integration fails silently or creates duplicates
You are adding a system and want it connected properly from the start
You cannot currently prove that two systems hold the same data

Probably not us if

You need data written directly into SAP tables for speed
The other system has no API and no supported export
You want an interface with no monitoring or reconciliation to keep the cost down

Common questions

Questions we are asked before a project starts

Can you integrate SAP Business One with our e-commerce platform?

Usually, yes. Orders, customers, stock levels, pricing and despatch status are the common flows, and they can run in both directions. What determines the effort is the quality of the other platform’s API and whether we can get a test instance of it. We will tell you early if the constraint sits on that side.

What happens when an integration fails?

That is designed before anything is built. Transient failures retry with backoff. Messages that cannot be processed go to an exception queue that a person can work, and a named contact is alerted. Nothing is silently discarded, and anything held can be reprocessed once the cause is fixed.

Will an integration keep our stock accurate?

It will keep the systems consistent with each other, which is a different thing from accurate. If stock is wrong in SAP Business One because of process problems — unrecorded adjustments, goods received late, picking errors — an integration will faithfully propagate that. We usually look at the underlying stock process at the same time, because integrating bad data just spreads it faster.

Do you use the Service Layer or the DI API?

The Service Layer for most integrations: it is service-oriented, works over HTTP and suits anything running outside the client. The DI API where logic needs to run alongside the Windows client or where a specific object is better handled there. Both go through SAP business logic, which is the point. We do not write to SAP tables directly.

Can you fix an integration somebody else built?

Yes, starting with an investigation of how it currently behaves. Duplicates, silent failures and missing reconciliation are the three things we find most often, and all three are usually fixable without rebuilding the whole interface.

Which two systems are not talking?

Tell us what moves between them today and who moves it. We will tell you what integrating them properly involves — and whether it is worth doing.