Service — System Integration
Keep the systems you already run. Stop typing the same record twice.
Integration is not a feature you switch on. It is a set of written decisions about which system owns which record, what happens when one of them is unavailable, and who gets told when a message is refused.
KodDelta builds two-way bridges between a company's operational system and the packages it already runs: Logo, Mikro, Netsis, SAP, e-invoice integrators, marketplaces, bank feeds and field hardware. Each field has one declared source of truth, and every bridge is designed for the remote system being down, a record being rejected, and a schema changing.
The hybrid model, and why we default to it
A company that has run an accounting package for years has a trained finance team, a chart of accounts that matches its filings, and an auditor who knows where to look. Replacing that is a large, risky project that produces no operational benefit. So the default architecture is hybrid, and in practice it works like this:
-
Accounting stays where it is
No migration, no retraining, no change to statutory filing. The finance team keeps the tool it knows, and the ledger keeps its continuity.
-
Operations move to the custom system
Work orders, field service jobs, approvals, dealer orders and inventory movement run in software built for the way they are actually done, described on custom software.
-
A bridge carries master data one way, transactions the other
Products, customers and price lists flow out of the system that owns them. Invoices, stock movements and cost entries flow back. Each direction is explicit, not incidental.
-
Conflicts are resolved by a declared source of truth per entity
Written into the integration specification before any code is written, so a disagreement between two systems has a documented answer rather than a meeting.
The effect on the operators is the point: an order is entered once. Whoever needs it next reads it rather than re-keys it. The wider argument about which work belongs in software at all is on business process automation.
The systems we bridge
These are the integration surfaces we have built against. Where a named connector does not exist, the generic surfaces underneath cover most of what remains.
Accounting and finance
Logo (Tiger, Go3, Netsis), Mikro Yazılım (Fly, Jump), SAP (S/4HANA, Business One), Zirve and Luca. Typical traffic: customer and product master data outbound, sales and purchase documents plus stock movements inbound, with a scheduled reconciliation so both sides agree on counts and balances.
E-invoicing and e-documents
GİB e-Fatura, e-İrsaliye, e-Arşiv and e-Müstahsil through integrator bridges (Sovos, Foriba, Digital Planet, EDM, Uyumsoft). The design work here is the rejection path: a document refused by the integrator has to reach a person with the reason attached, not sit in a queue marked sent.
E-commerce and marketplaces
Already built: Trendyol, Hepsiburada, Amazon, Shopify and WooCommerce. Not pre-built, and we will not pretend otherwise: bol.com, Mirakl, Channable, Peppol-based invoicing, and the Benelux accounting stack (Exact Online, AFAS, Twinfield). These are built as custom connectors — typically 1–3 weeks each where the platform has a documented API, quoted separately and named in the contract before work starts. Ask us for the estimate on yours rather than assuming it is missing. Order intake in, stock and price out. The hard part is not the API but the reservation rule: what a quantity means when the same physical stock is offered on three channels at once.
Banking and payments
Virtual POS (Garanti, Akbank, İş Bankası, Yapı Kredi, Iyzico, PayTR) and MT940 account-movement import. Incoming payments are matched to open documents by reference, and unmatched movements are listed for a person instead of being force-matched by amount.
Warehouse and field hardware
Handheld terminals, barcode and QR scanners, RFID gates, weighbridge and scale indicators. A scanner is an input device with its own failure modes: duplicate scans, partial reads and readings taken while a device is offline all need explicit handling.
Generic surfaces
REST and SOAP APIs, SFTP file exchange, direct database views and webhook receivers. Most integrations that have no documented connector still have one of these underneath, which is what makes an older on-premise system reachable.
Source of truth: the decision that prevents the month-end argument
In any company running more than one system, some records exist in two places. That is normal and not the problem. The problem is when both copies are editable and both systems believe they are authoritative, because then they diverge slowly and nobody notices until a reconciliation fails.
So before code is written we produce a short table: for each entity, which system creates it, which system may change it, which fields cross the boundary and in which direction. It looks like this, and the actual content differs per company:
| Entity | Owned by | What crosses the boundary |
|---|---|---|
| Customer master | Accounting package | Read-only copy into operations; a new customer created in the field opens a request rather than a record |
| Product and price list | Accounting or PIM | Outbound to operations and to sales channels, on a schedule with a version stamp |
| Work order / service job | Operational system | Nothing inbound; only its financial result leaves |
| Stock movement | Operational system, at the point of physical movement | Posted to accounting as documents, not as a nightly balance overwrite |
| Sales invoice | Accounting package | Operations submits the draft; the accounting document number returns and is stored against the job |
| Marketplace order | Marketplace | Inbound only; status and tracking go back out, the order itself is never edited locally |
Two rules make this hold. Records that arrive from a remote owner are not editable locally, because an edit that cannot be pushed back is a lie that survives until the next sync. And every crossing record keeps the remote identifier, so any row on either side can be traced to its counterpart without a name match.
What makes an integration straightforward, and what does not
The difference matters because it is the difference between a bridge that takes days and one that takes weeks, and it can be assessed before anyone commits to a price.
Straightforward: the existing system exposes a documented API or a stable database view; master data carries consistent identifiers on both sides; one system is clearly the source of truth for each entity.
Difficult:
- Identifiers differ and have to be matched by name. Company names with different punctuation, product descriptions with different spacing. This needs a mapping table, a matching rule and, above all, a defined destination for records that do not match — a review queue, never a guess.
- The remote system only exports files on a schedule. That caps freshness at the export interval, and it makes ordering and partial files the integration's problem. It is workable; it is not real time, and it should not be sold as such.
- Both systems consider themselves authoritative for the same record. This is an organisational decision disguised as a technical one, and it has to be settled by the client before the bridge is built.
- Undocumented behaviour. A field that is optional in the documentation but mandatory in practice, a rate limit that is not published, a status code reused for two meanings. This is discovered in testing, which is why bridges are tested against the real remote system and not only against a specification.
The failure modes every bridge is designed for
An integration that only works when everything is up is not an integration; it is a demonstration. These are the conditions that occur in normal operation, and the behaviour we build for each.
| What goes wrong | Naive behaviour | How the bridge is built |
|---|---|---|
| The remote system is down | The request fails, the error is logged, the record never arrives | Queued retry with a visible backlog: count, age and oldest item on screen, draining in order when the remote returns |
| A record is rejected | The rejection goes into a log nobody reads; the record is assumed sent | Surfaced to a named owner with the reason attached, and held in a state that reads as failed rather than sent |
| Duplicate delivery | A retry after an uncertain response creates a second invoice or deducts stock twice | Idempotency key on every message; a repeat of the same key returns the original result instead of acting again |
| Schema change on the other side | A renamed field silently arrives empty and nobody notices for weeks | Versioned contract with expected fields and types; a mismatch raises an alert instead of writing a partial record |
| Partial batch | Half the file is imported, the run is marked complete, the rest is lost | All-or-nothing per batch with a resumable position, so a re-run neither skips nor repeats rows |
| Slow drift between the two sides | Discovered at month end, reconciled by hand | Scheduled reconciliation comparing counts and balances per period, with the differences listed rather than a pass/fail flag |
Two further points follow from this table. Alerts go to a named person, not to a shared address, because an alert everyone can see is an alert nobody owns. And the backlog is a business screen rather than an engineering dashboard, so the operations manager can see that forty documents are waiting without asking anyone.
When an integration is not worth building
- The volume is a handful of records a month. A person copying twelve rows once a month costs less than a bridge that has to be maintained through both systems' upgrades.
- The remote system is being replaced this year. Build the bridge to the successor, or wait. A bridge to a system with a known end date is spend with a known end date.
- Nobody will own the exceptions. Every bridge produces rejected and unmatched records. If no named person will work that queue, the queue grows and the integration becomes a source of quiet errors instead of a fix.
- The two systems disagree about the process, not the data. When the real problem is that two departments define an order differently, connecting the databases makes the disagreement faster, not smaller. Settle the definition first.
How an integration project runs
-
Surface audit
We establish what each system actually exposes: API, database view, file export or nothing. This is a factual exercise and it decides feasibility and price. Often it turns up an export nobody in the company knew existed.
-
Written integration contract
Every field that crosses the boundary, its direction, its source of truth, the trigger, the retry policy and the owner of each alert. This document is delivered to you and it is what makes the bridge maintainable by anyone.
-
Build and parallel run
The bridge runs alongside the manual method, writing to a staging area first. Outputs are compared against what the people were producing by hand until they match, then the manual step is retired.
-
Reconciliation and monitoring in production
Scheduled comparison of counts and balances, a visible backlog, and alerts to named owners. A bridge is not finished when the first record crosses; it is finished when a failure is noticed by the system rather than by a customer.
Integration work is usually scoped as part of a build: a single focused module is $3,000–6,000 over 2–4 weeks, a multi-department system $8,000–15,000 over 4–8 weeks. The bands are on pricing, and the data-migration side is covered on migration guide. Operational systems that sit on top of these bridges are described on manufacturing, field service and dealer portal.
Frequently Asked Questions
Which systems does KodDelta integrate with?
Accounting and finance packages including Logo (Tiger, Go3, Netsis), Mikro (Fly, Jump), SAP (S/4HANA, Business One), Zirve and Luca. Turkish e-document systems, meaning e-Fatura, e-Arsiv, e-Irsaliye and e-Mustahsil, through integrator bridges such as Sovos, Foriba, Digital Planet, EDM and Uyumsoft. E-commerce and marketplaces including Trendyol, Hepsiburada, Amazon, Shopify and WooCommerce. Banking through virtual POS and MT940 account movement import. Warehouse and field hardware such as handheld terminals, barcode and QR scanners, RFID gates and weighbridge indicators. Where no named connector exists, the generic surfaces are REST and SOAP APIs, SFTP file exchange, direct database views and webhook receivers.
Do we have to move our accounting into the new system?
No, and we normally advise against it. The default architecture is hybrid: statutory accounting stays in the existing package with no migration and no retraining of the finance team, while operational processes such as work orders, field service, approvals, dealer orders and inventory movement run in the custom system. A bridge synchronises master data one way, meaning products, customers and price lists, and transactional data the other, meaning invoices, stock movements and cost entries.
What is a single source of truth and why does it matter?
It is a written decision, taken per entity before any code exists, about which system is allowed to create and change a given record. Accounting may own the customer master while the operational system owns the service history; the warehouse system may own physical stock while the store owns the reservation. The failure being prevented is not data living in two places, which is normal, but both places believing they are authoritative and diverging silently until someone notices at month end.
What happens when the other system is offline?
The message is queued and retried, and the backlog is visible on a screen with a count and an age rather than buried in a log file. Nothing is dropped and nothing is silently overwritten. When the remote system returns, the queue drains in order. Every message carries an idempotency key, so a message that is retried after an uncertain response does not create a second invoice or deduct stock twice.
What makes an integration difficult to estimate?
Three things, and they belong in the estimate rather than in the surprise column. First, identifiers that differ between systems and have to be matched by name, which is never reliable at scale and needs a mapping table plus a rule for unmatched records. Second, a remote system that only exports files on a schedule, which caps how fresh the data can be and makes ordering the operator's problem. Third, two systems that both consider themselves authoritative for the same record. All three are solvable; each one adds work.
What happens when the remote system changes its API?
The bridge holds a versioned contract listing every field it expects, with types and required flags. When the remote payload no longer matches, the bridge raises an alert to a named owner rather than accepting a partial record. This is deliberate: the expensive failure is not a bridge that stops, which someone notices the same morning, but a bridge that keeps running while one field silently arrives empty for six weeks.
Tell us which two systems are not talking.
Name the packages, the records that cross between them and how often. We come back with the integration surface, the source-of-truth table and a fixed price.