The forwarding division ran on CargoWise. Finance ran on SAP. And every invoice, every credit note, every receipt existed in one system only because someone had sat down and typed it into the other.
Accounts receivable. Accounts payable. Credit notes. Debit notes. Every financial transaction the business generated in CargoWise had to be manually extracted, reformatted, and re-entered into SAP — the legacy ERP the parent group mandated for financial consolidation. Every payment receipt SAP processed had to travel the same route in reverse: pulled from SAP, reformatted, manually posted back into CargoWise to close the loop on the original transaction.
Two systems. Legitimate, non-negotiable reasons for both to exist. No automated connection between them. And a finance team spending its operational capacity as a human middleware layer — converting data formats, re-keying numbers, and reconciling the inevitable discrepancies that surface when the same information lives in two places and neither copy was created by the other.
The Canadian logistics subsidiary of one of the world's largest automotive groups — a global operation spanning vehicle distribution, freight forwarding, warehousing, and supply chain management across five continents. The Canadian arm handles freight forwarding and transportation services specialising in automotive distribution — complex supply chains, high-value cargo, and a compliance environment where financial accuracy is not negotiable.
CargoWise One ran the forwarding operation. SAP ran the group's global financial consolidation. Both platforms were doing exactly what they were designed to do. The problem was between them.
The Problem Was Structural
This was not a configuration issue. It was not a missing feature. The problem was architectural — two enterprise platforms, each with its own data model, its own format, its own financial logic, running in parallel with no system-level connection between them.
CargoWise One is purpose-built for freight forwarding. When the operations team booked a shipment, processed a customs entry, or managed a warehouse consignment, CW1 generated the financial transactions — invoices, payables, credit notes, debit notes — as part of the operational workflow. The financial data was native to the system, structured in XML, and available the moment the operational event occurred.
SAP is built for enterprise financial management. The parent group ran global financial consolidation through SAP. Every subsidiary, every country, every division reported through the same ledger structure. SAP expected its financial data in CSV format, received through a designated FTP channel, and processed against its own chart of accounts.
The forwarding operation needed CargoWise. The parent group needed SAP. Neither platform was optional. And neither could read the other's financial data without human intervention.
So the finance team became the bridge. Every working day, they extracted financial transactions from CargoWise, translated them from XML into a format SAP could ingest, and re-entered them. When SAP processed a payment receipt, they extracted it, translated it back into XML, and posted it into CargoWise so the original invoice could be marked as paid. The same data. Two formats. Two systems. Entered by hand, every time.
What That Was Actually Costing
The labour hours were the visible cost. The structural damage was harder to see — and it was the part that threatened the operation's growth trajectory.
- Every transaction touched at least twice. An invoice posted in CargoWise existed in CargoWise. Until someone re-keyed it into SAP, the group's financial ledger didn't know it existed. A receipt posted in SAP existed in SAP. Until someone re-keyed it into CargoWise, the forwarding system still showed the invoice as unpaid. The finance team wasn't managing finances. They were synchronising databases.
- Reconciliation consumed every month-end. Two independently maintained copies of the same financial data will diverge. A transposed digit here. A credit note posted in CW1 but not yet entered in SAP there. Every month-end close began with a reconciliation exercise across both systems — identifying mismatches, tracing errors to their source transaction, correcting them in whichever system was wrong. The close wasn't slow because the business was complex. It was slow because the data was duplicated.
- Errors discovered late. Manual re-entry introduces errors at a predictable rate — industry benchmarks place it between 1% and 4% per transaction. For a forwarding operation processing hundreds of financial transactions per day, that rate produced a steady stream of discrepancies. Each one invisible until reconciliation surfaced it, days or weeks after the original entry. By then, the operational context was gone. Tracing a mismatched invoice back to the shipment that generated it, across two systems, across two formats, consumed senior finance time that produced no forward value.
- No real-time financial visibility. The group's financial reporting depended on SAP. But SAP's data was only as current as the last manual entry. A shipment invoiced in CargoWise at 9am might not appear in SAP until the following day — or later, if the finance team was behind. Cash position, revenue recognition, AR ageing — every financial metric the business relied on ran on a delay defined not by system performance, but by how fast a person could re-key data from one platform into another.
- The process did not scale. Every new shipment generated financial transactions. As volume grew, the number of manual entries grew with it — linearly, with no efficiency gain. The business was growing. The finance team's capacity to keep two systems synchronised was not. The constraint was not technology. It was arithmetic.
The dual-system financial architecture is one of the most common integration gaps in freight forwarding. A forwarding operation runs on CargoWise because it is the platform built for the work. A parent group, a holding company, or a global finance function runs on SAP, Oracle, or NetSuite because it serves the wider enterprise. The operational logic is sound. The integration gap between them — financial data that must be manually extracted, reformatted, and re-entered — is the structural cost. As forwarding groups consolidate, as parent organisations mandate unified financial reporting, and as transaction volumes grow, the manual bridge becomes the single most fragile process in the financial workflow. The businesses that automate it build a scalable finance function. The ones that do not feel it in every month-end close.
Why SFL
The challenge was not writing a file transfer script. Any integration vendor can move a file from point A to point B. The challenge was building an integration that understood both systems deeply enough to guarantee that what came out of one arrived correctly in the other — across different data formats, different financial logic, different transaction lifecycles — and did it reliably enough that the finance team could stop checking every entry by hand.
That required a partner that understood CargoWise at the platform level. How CW1 structures financial transactions internally. How its workflow engine triggers outbound data. How its XML schemas represent invoices, credit notes, and receipts — including the edge cases that a surface-level integration would miss and a production finance workflow would not forgive.
SFL brought both the platform expertise and the middleware discipline. As a CargoWise All-Platinum Certified Service Partner — Platinum accreditation across every module including Accounting, Workflow, and Integration — SFL had delivered 895+ CargoWise implementations across 50+ countries and built 140+ operational integrations connecting CargoWise to external systems. The team had designed and deployed middleware for CargoWise-to-ERP financial integrations before. The architectural pattern, the transformation logic, the validation layers, the error handling — this was not a first attempt. It was a proven capability applied to a specific client's architecture.
What SFL Built
SFL designed, developed, and deployed a custom middleware integration service that automated the entire bi-directional financial data flow between CargoWise One and SAP — eliminating manual extraction, reformatting, and re-entry across all five transaction types.
- The outbound flow — CW1 to SAP
When the forwarding operation posts an invoice, an accounts payable entry, a credit note, or a debit note in CargoWise, CW1's workflow engine triggers an automated outbound. The financial transaction data is generated in XML format and delivered to a designated FTP channel.
The SFL middleware picks up the XML file, extracts the transaction data, validates it against the business rules governing SAP's expected format, transforms it from XML to CSV, and delivers the structured file to SAP's inbound FTP channel. SAP ingests the file and posts the transaction to the general ledger — without re-entry, without reformatting, without a person in the loop.
Four transaction types flow through this path: accounts receivable, accounts payable, AR credit notes, and AP credit notes. Each carries its own schema, its own field mapping, its own validation rules. The middleware handles all four through a single configurable framework — one architecture, four rule sets.
- The inbound flow — SAP to CW1
When SAP processes a payment receipt against an invoice, the receipt data is generated in CSV format and placed on the FTP channel. The SFL middleware retrieves the file, transforms it from CSV to XML structured to CW1's receipt posting schema, and posts it into CargoWise. The original invoice in CW1 is automatically updated to reflect the payment — closing the financial loop without manual intervention.
This was the step the manual process handled worst. Receipts posted in SAP but not yet reflected in CW1 meant the forwarding system showed invoices as unpaid when they had already been settled. The automated inbound flow eliminated that lag entirely.
- The architectural choices that mattered
The middleware was not a point-to-point file converter. SFL built it as a structured integration service with distinct layers for extraction, validation, transformation, and delivery — each operating independently. A change in SAP's CSV format specification does not require rebuilding the CW1 extraction logic. A change in CW1's XML schema does not break the SAP delivery process. The architecture absorbs change without propagating it across the entire integration.
Validation was built into the transformation layer, not bolted on after deployment. Every transaction is checked for structural integrity, required field completeness, and format compliance before it reaches the destination system. Errors that the manual process would have introduced and discovered weeks later at reconciliation are caught at the point of transfer — before they enter either system's financial records.
The FTP-based transport layer aligned with the client's existing infrastructure and SAP's standard inbound mechanisms. The middleware handles file polling, pickup confirmation, delivery acknowledgment, and retry logic for failed transfers — the operational reliability layer that separates a production integration from a development prototype.
The Results
Every problem above has a corresponding outcome below.
- Manual dual-entry eliminated across all five transaction types — AR, AP, credit notes, debit notes, and receipts flow automatically between CW1 and SAP. The finance team that had been re-keying every financial transaction into two systems no longer touches the data transfer. The process that scaled linearly with transaction volume now scales at zero incremental cost
- Reconciliation burden removed at source — two systems now receive the same data through the same automated pipeline. The month-end reconciliation exercise that consumed days of senior finance time — tracing mismatches, identifying re-entry errors, correcting them across both systems — was eliminated because the data matches. It was never manually duplicated
- Error rate reduced to system-level precision — manual re-entry error rates of 1–4% per transaction replaced by validated, automated transformation with pre-submission integrity checks. Errors that previously surfaced weeks later during reconciliation are now caught before the data enters either system
- Real-time financial visibility restored — financial transactions appear in SAP within the middleware's processing cycle, not when the finance team gets to them. Cash position, revenue recognition, AR ageing, and group financial reporting run on current data — not data that lags a day or more behind the operation
- Finance team redeployed to financial management — the people who had been operating as a human middleware layer — extracting, reformatting, re-entering, reconciling — were freed to do the work the business hired them for: financial analysis, cash management, reporting, and decision support
- Production-grade reliability from day one — the integration runs with automated error handling, retry logic, and transfer validation. The finance team does not monitor it. It runs
Is Your Finance Team Operating as a Human Middleware Layer?
The pattern is more common than it should be. A forwarding operation runs on CargoWise. The parent group or the finance function runs on SAP, Oracle, NetSuite, or another ERP. Both systems are legitimate. Both are necessary. And between them sits a finance team, manually extracting data from one, reformatting it, and re-entering it into the other — every transaction, every day.
It is a solvable problem. The middleware architecture SFL built here automates the full financial data lifecycle between CargoWise and external ERPs — extraction, validation, transformation, and delivery, bi-directionally, with production-grade reliability. 140+ operational integrations delivered. 34+ financial system integrations. 895+ CargoWise implementations across 50+ countries.
About SFL
SFL is a CargoWise All-Platinum Certified Service Partner — the highest accreditation WiseTech Global awards — with Platinum certification held across every module including Forwarding, Accounting, Customs, Warehousing, Workflow, Integration, and Global Rollouts. With 895+ implementations delivered across 50+ countries, 250+ integration clients, and 60+ CargoWise-certified specialists, SFL works exclusively within the CargoWise ecosystem to build the integrations, automations, and operational infrastructure logistics businesses need to grow.
SFL's integration practice includes 140+ operational integrations, 34+ financial system integrations, and 20+ e-invoicing integrations — connecting CargoWise to the ERP, compliance, and operational systems logistics businesses depend on.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
