Interfaces that connect your systems
Inventory management, industry software, accounting, time tracking, warehouse: in companies that have grown over the years, the same information sits in several places and is carried across by hand. We connect those systems using whatever route they offer — an application programming interface, event-driven calls, a governed file exchange or an intermediate layer. The fixed price is set once the process analysis is done.
Delivery · net plus VAT
- Scope and price in writing before delivery starts
- Field mapping and error handling are part of the quote, not an add-on
- Trial run with real transactions from your business before sign-off
- Monitoring and a named contact after the rollout as well
Building an interface starts at 4,900 € net as a fixed price that is set once the analysis is complete. The entry point is the process analysis from 1,900 € net, covering the on-site review, a written report and a prioritised list of measures. Ongoing support for the connections we set up starts at 190 € net per month. All prices are net plus VAT; third-party licences, access fees and charges are shown separately. The full breakdown is on the pricing overview.
Prices as of September 2026. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
In most mid-sized companies there is no single system that does everything — but there are several that each do part of the job very well. Inventory management knows the items, industry software knows the jobs, accounting knows the documents, time tracking knows the hours. The effort sits in between: somebody reads a value in one programme and types it into the next. An interface takes over exactly that handover — reliably, traceably and without anyone having to remember it.
A handover point between two programs
What an interface does day to day
An interface is an agreed handover point between two programmes. One system provides data or reports a change, the other receives it and processes it in its own structure. Day to day this means a new job is created once and is then visible in the systems that need it. An address change is maintained in one place and travels onwards from there. A completed transaction produces the document automatically instead of being reconstructed from a list at month end. The benefit shows less in minutes saved per transaction than in the queries that disappear because two departments look at the same status.
The routes two systems use to talk to each other
Which route is available is decided by the programmes involved, not by preference. Modern software usually ships with a documented application programming interface. Older line-of-business applications sometimes offer nothing more than an export to a file or read access to their database. In practice we combine several routes within one project: one partner is addressed through its API, the other drops a file into a monitored directory. For daily operation that makes no difference, as long as the handover is logged, repeatable and monitored.
Programming interface (REST)
The direct route: a system exposes endpoints for reading, creating and updating records. We work with the documentation that exists, settle authentication and access limits, and respect the call frequency the vendor allows.
Event-driven calls
Instead of asking repeatedly, the source system reports changes itself. Such webhooks keep the delay small and the load low. We protect them against duplicate and delayed notifications, because both occur in live operation.
Governed file exchange
Where a programme can only export, file exchange becomes the transport route. Location, naming scheme, format and schedule are agreed, every processed file is archived, and faulty rows land in a traceable holding area rather than nowhere.
Direct database coupling
With legacy systems that offer no interface, read access to the database is sometimes the only option left. We use it sparingly, prefer read-only access and encapsulate the queries so that replacing the system later does not affect half the landscape.
Middleware as a broker
From three systems onwards an intermediate layer pays off. It receives data, converts formats, remembers the state and distributes onwards. Each system then knows only the layer instead of every other system, which keeps later replacements manageable.
Queue and retry
Handovers run through a queue that buffers each job. If a target system is temporarily unavailable, nothing is lost: the job stays queued and is retried at growing intervals until it succeeds or is reported.
The questions that define the scope before anything is built
The technical connection is rarely the hard part. It becomes hard when nobody has decided which system wins in the event of a conflict. That is why we settle four points before the first line of code is written. The answers are then recorded in the concept document and form the basis for the fixed price.
Direction per data type
Do items flow one way while addresses flow both ways? The direction is defined separately for each data type. Two-way transfer is possible, but it needs a rule stating which side wins when both change at once.
Trigger and frequency
Immediately on every change, every fifteen minutes or once overnight? The answer depends on how quickly the information is needed and how much load the systems tolerate. For many workflows a tight schedule is enough; true simultaneity is not required.
Keys and matching
Two systems have to recognise that they are dealing with the same customer or the same item. We define which field serves as the key and maintain a matching table where needed, rather than guessing at numbers.
Data ownership and permissions
Which system owns which field, and who may write there? The technical account receives only the rights required for the agreed data flows — read where reading happens, write only where writing is intended.
Field mapping: where the real work sits
Two programmes rarely name the same thing the same way. One holds a customer number as text with leading zeros, the other as a number. One keeps net and gross prices separately, the other converts. One stores an address in a single field, the other in five. For every data type we therefore produce a mapping table: source field, target field, conversion rule, mandatory yes or no, behaviour when a value is missing. That table is unglamorous and still the most valuable document in the project, because it makes every later deviation explainable.
- Customer, item and document numbers: format, leading zeros, upper and lower case
- Prices and tax: net or gross, tax rate, rounding, currency
- Quantities and units: pieces, kilograms, metres, conversion factors, decimal places
- Date and time: format, time zone, behaviour when a value is missing
- Characters and encoding: umlauts, special characters, field lengths and truncation
- Statuses and flags: what "open", "delivered" or "cancelled" is called in each system
Errors, retries and idempotency
Networks drop out, systems go into maintenance, access tokens expire, and sooner or later a record arrives that nobody anticipated. A robust interface expects this. It distinguishes between a temporary problem that a retry resolves and a content error that a person has to look at — an unreachable counterpart belongs to the first group, a missing mandatory field to the second. Temporary failures are retried at growing intervals; content errors land in a holding area together with the complete transaction, so it can be replayed after the correction instead of being lost.
Idempotency in one sentence
Monitoring: an interface reports before anyone asks
An interface works invisibly, and that is both its biggest advantage and its biggest risk. As long as everything runs, nobody thinks about it. If the overnight run fails to happen, in the worst case it only surfaces at month end. That is why every connection we set up comes with monitoring — not as an add-on package, but as part of the delivery.
Run log
Every run is recorded with timestamp, number of records, duration and result. When accounting raises a query, it can be traced whether a transaction was transferred and what happened to it.
Alert on a missing run
It is not only errors that raise an alert, but also the absence of an expected run. A transfer that goes quiet is the case that stays unnoticed longest, so it is monitored in its own right.
Business control figures
Beyond the technical side we check numbers your staff understand: jobs per day, the sum of transferred line items, the count of open error cases. Deviations then surface even when everything looks technically green.
Why an interface is more than a one-off data migration
When a system is replaced, data is migrated once: stock, customers and items move into the new environment, and the task is then complete. An interface begins where that migration ends. It is a component of daily operation that works every day while both sides keep evolving: the vendor of one system publishes a new API version, another adds a mandatory field, an access token expires, a tax rate changes. That is why we plan interfaces like equipment that is operated — with logging, retries, a holding area for failures, documentation and a named contact. A one-off migration needs none of that; a permanent connection needs all of it. Treating both the same way means paying the difference later in manual work. More on consolidating scattered records into one shared data basis is on the data integration page; the step-by-step replacement of outdated programmes is described under legacy replacement.
Three ways to bring two systems together
All three occur in mid-sized companies. Which one holds up depends on how often the handover happens and what an error costs.
Carrying data across by hand
- Included: Available straight away, nothing to set up
- Included: Sensible where there are only a few transactions a week
- Not included: Ties up working time that grows with the business
- Not included: Typing errors stay undetected for a long time
- Not included: During holidays or sickness the handover simply stops
One-off data migration
- Included: The right choice when replacing a system or consolidating records
- Included: Clearly bounded effort with a defined end point
- Not included: The state starts ageing the day after the migration
- Not included: No retries and no holding area for failures are foreseen
- Not included: Repeated regularly, it turns into manual work every month
A permanent, monitored interface
- Included: The handover runs on the agreed schedule without intervention
- Included: Retries on disruption, a holding area for special cases
- Included: Run log and an alert when a run fails to happen
- Included: Fixed price from 4,900 € net, scope in writing before the start
- Not included: One more component that has to be operated and maintained
How an interface project runs
Review of the systems involved
We look at which programmes are in play, which versions are running and which transport routes they offer. That includes reading the existing documentation, testing the access paths and asking who holds the contract with each vendor. The result is a list of possible routes and their limits.
Defining direction, cadence and ownership
Together with your departments we define, per data type, in which direction data flows, how often, and which system wins in the event of a conflict. This is where the decisions are made that later determine whether two reports show the same figure.
Describing field mapping and error cases
Every field gets its counterpart, every conversion its rule. In parallel we describe what should happen with missing mandatory values, unknown keys or unreachable systems. The fixed price is derived from this document.
Building in a test environment
The interface is built away from daily operation. We set up transport, queue, retries and logging and check each data flow against test data first, so that nothing appears in the production system that does not belong there.
Trial run with real transactions
Before sign-off, the interface runs with transactions from your business, deliberately including the awkward ones: cancellations, partial deliveries, special prices, a customer without a tax number. Your department checks the result where it works every day.
Handover, monitoring and support
At the end you receive the field mapping, a short operating guide and access to the run log. Monitoring is active from day one. As part of ongoing operations and maintenance we adjust the connection whenever one of the systems changes.
We look at which programmes are in play, which versions are running and which transport routes they offer. That includes reading the existing documentation, testing the access paths and asking who holds the contract with each vendor. The result is a list of possible routes and their limits.
Together with your departments we define, per data type, in which direction data flows, how often, and which system wins in the event of a conflict. This is where the decisions are made that later determine whether two reports show the same figure.
Every field gets its counterpart, every conversion its rule. In parallel we describe what should happen with missing mandatory values, unknown keys or unreachable systems. The fixed price is derived from this document.
The interface is built away from daily operation. We set up transport, queue, retries and logging and check each data flow against test data first, so that nothing appears in the production system that does not belong there.
Before sign-off, the interface runs with transactions from your business, deliberately including the awkward ones: cancellations, partial deliveries, special prices, a customer without a tax number. Your department checks the result where it works every day.
At the end you receive the field mapping, a short operating guide and access to the run log. Monitoring is active from day one. As part of ongoing operations and maintenance we adjust the connection whenever one of the systems changes.
Typical situations that lead to an interface
Illustrative scenarios from typical project work (project experience), anonymised and without client details.
What an interface costs
We name prices before you have to ask for them. The entry point is the process analysis: it shows which handover actually ties up time and whether an interface is the right lever or a simpler automation is enough. On that basis we set a fixed price per connection with the scope written down. What moves the price is not the number of fields but the number of special cases: how many data types are involved, whether transfer runs both ways, whether the counterpart has usable documentation, and how many exceptions your workflow knows.
Prices for interfaces
All prices net plus VAT. The binding fixed price per connection is set once the process analysis is complete.
Process analysis
The entry point: where does the manual work arise and what gets connected first?
- Recording the handovers between your systems
- Review of existing interfaces and exports
- Media breaks and duplicate entry identified
- Written report with prioritised measures
- Effort estimate per possible connection
Build the interface
A fixed price per connection, with the scope agreed in writing.
- Connection via API, webhook, file or database
- Field mapping, conversion rules and keys documented
- Queue, retries and a holding area for failures set up
- Trial run with real transactions before sign-off
- Run log and a short operating guide included
Ongoing support
So the connection holds up when the systems change.
- Monitoring of the transfers we set up
- Alerts when an expected run does not happen
- Fault resolution and review of the holding area
- Adjustments for new versions and changed fields
- A named contact who knows your landscape
All prices net plus VAT. Third-party licences, access fees and charges are shown separately. You receive a binding quote after the process analysis.
Scope: inventory systems and online shops in retail
Two systems that do not talk to each other?
Tell us briefly which programmes are involved and which information is carried across by hand today. We will tell you which route is realistic, what it costs and in which order it makes sense.