01
The dilemma
This client had already done the hard part. They had a custom operations application that fitted their business precisely and a proper accounting ledger. What they did not have was a connection between them, and the gap was being filled by people typing.
What was breaking
- Operations and accounting were separate worlds. Financial records lived in the ledger while daily operations ran in the custom app, producing synchronization delays that grew with volume.
- Confirmed sales orders required manual re-entry. Turning an agreed order into an actionable invoice meant a person retyping it, with everything that implies for accuracy and speed.
- Complex pricing rules did not survive the gap. Customer-specific price lists and calculations had to be reapplied manually on the accounting side.
- Master data drifted. Customer short names and item master fields were not syncing cleanly, so the same entity existed slightly differently in two systems.
- Approvals were duplicated. The same decision was being recorded twice because neither system trusted the other's record of it.
The cost of standing still
In wholesale distribution, the delay between a confirmed order and a raised invoice is the delay in getting paid. Manual re-entry is not only an error source, it is a financing cost, paid every day, on every order, forever.
02
The idea
The client expected to be told to abandon one system. We did not think so. Both platforms were doing their jobs well; what was missing was engineering discipline in the space between them. We built a proper bi-directional bridge with failure protection, rather than a fragile one-way push that would break silently at the first API timeout and be discovered at month-end.
The principles we worked to
- Keep both systems, engineer the join. The operations app fitted the business and the ledger fitted the accountants. The gap was the problem.
- Design for failure first. API calls fail. A bridge without failure protection is a data loss incident with a delay on it.
- Move the pricing logic into the integration. So the rules are applied once, in one place, consistently.
- Eliminate duplicate approvals. A decision recorded in one system should be authoritative in both.
What we ruled out, and why
| Option considered | Why we did not take it |
|---|---|
| Consolidating everything into the accounting platform | Would have discarded a custom operations app that genuinely fitted the business, in exchange for a worse operational fit. |
| A scheduled overnight file export | Cheap, common, and it preserves exactly the synchronization delay that was the complaint. |
| An off-the-shelf connector | None handled the customer-specific price list logic or the custom master data fields this business depended on. |
03
The build
The bridge was built in five parts.
Bi-directional API bridge with failure protection
A reliable connection between the operations app and the ledger, engineered with explicit API failure handling so that a transient error is retried and reported rather than silently dropped.
Automated pricing integration
Complex price list integrations and calculations automated through Deluge scripting, so customer-specific pricing is applied consistently without manual reapplication.
Purchase workflow and credit notes
The purchase order workflow mapped and automated end to end, a credit notes module built to handle returns and adjustments properly, and redundant approvals removed from both sides.
Master data mapping
Customer short names, item master fields and related identifiers mapped explicitly between systems, so the same entity is the same entity everywhere.
Analytics and delivery documentation
Synced data pushed into analytics to generate automated, color-coded delivery notes, operational documents produced from the same records that drive the accounts.
04
The impact
| Measure | Before | After |
|---|---|---|
| Synchronization | Delayed, batch-dependent | Zero delay, bi-directional |
| Order to invoice | Manual re-entry | Automated, no retyping |
| Pricing application | Reapplied by hand | Automated through scripted price lists |
| Master data | Drifting between systems | Explicitly mapped and consistent |
| Purchase orders | Partly manual | Mapped and automated |
| Credit notes | Handled ad hoc | Dedicated module |
| Approvals | Duplicated across systems | Recorded once, authoritative in both |
| Delivery notes | Prepared manually | Automated and color-coded from synced data |
Beyond the numbers
- Frictionless invoicing. A confirmed order becomes an invoice without a person in the middle, which shortens the time to payment.
- Transaction validation and pricing became automatically accurate. The error class was removed rather than policed.
- One trustworthy source of truth. Operational clarity across the business, with both systems agreeing by design.
05
What comes next
The engagement continues. These are the next moves on the table.
- Extending the bridge to purchase and supplier settlement.
- Customer-facing order status drawn from the same synced records.
- Margin analytics per customer and per item on unified data.
Engagement delivered by the Ideentrix founding team. Technologies, scope and outcomes as recorded at project close, published with the client's consent.
