A symptom, and its probable causes
Pick what you observe. You will see what we look at first and why — a slice of the diagnostic reasoning, applied to the most frequent cases.
What are you seeing?
Our operators retype the customs documents
What you see
The file arrives as an attachment — a scan, a fax, sometimes a photograph of a paper document — and somebody copies the same fields into the TMS. When two documents disagree, the gap surfaces at the terminal.
Most frequent causes
- 01
The document enters no automated pipeline at all
frequentThe file arrives by email and stops there: nothing reads it, nothing reconciles it against the order. Human entry is the only bridge between the document and the TMS, and it is rebuilt on every file.
- 02
Generic OCR was put in, but no reconciliation
frequentThe extraction works and returns a flat file. Because no field is checked against your order data, somebody still has to clean them up before the TMS will accept the payload: the re-keying moved desks, it did not go away.
- 03
The check exists, but it happens too late
commonThe gap between the net weight on the packing list and the gross weight on the bill of lading does get seen — downstream, or at the terminal. By then it is no longer a data-entry correction: the container has landed and demurrage is accruing.
- 04
The TMS will not take the structure produced
rarerThe data is right, but what gets sent is not what the TMS expects — a valid eAdaptor payload, for CargoWise. The import fails, the team falls back to screen entry, and the workaround becomes permanent.
What we look at, in this order
- 01The document as it actually arrives: the scan, the fax, the photograph — not the clean version reconstructed afterwards.
- 02What is being retyped exactly, field by field, and out of which document.
- 03The fields already present in your order data and re-keyed anyway.
- 04What happens when two documents contradict each other: who decides, at what point, and on what basis.
- 05The integration surface your TMS exposes, and the structure it expects.
What the fix involves
Put the document into a pipeline that ingests it as it arrives, reconcile the fields against your order data before anything is transmitted, and send the TMS only a payload that has already been validated. Discrepancies come back to your operators; the rest stops passing through them.
Related area
Customs pre-clearanceThese chains are the most common ones, not the only possible ones. Establishing the real cause on your flows, with your messages, is precisely what the diagnostic is for.
Our invoices come back rejected
What you see
The invoice goes out, a response comes back with an error code, and nobody on the team can translate it into a concrete action.
Most frequent causes
- 01
A mandatory field missing or malformed
frequentAn identifier, an order reference or a required mention is absent — or present, but in a format the recipient does not accept.
- 02
A business rule not honoured
frequentThe structure is valid but a check fails: line totals inconsistent with the header, an unexpected VAT rate, a currency or rounding that does not match the expected profile.
- 03
The wrong content profile
commonThe document is syntactically correct but does not honour the profile the channel requires. Valid XML is not necessarily an acceptable document.
- 04
Wrong data upstream
rarerThe flow works: it is the data coming out of the ERP that is wrong. Fixing the flow would change nothing.
What we look at, in this order
- 01The raw message actually transmitted — not the PDF, not the preview.
- 02The recipient response in full, including secondary codes.
- 03The exact rule that fails, compared against the expected profile.
- 04Whether the same invoice fails on one channel and passes on another.
- 05The source data in the ERP, to separate flow from content.
What the fix involves
Fix how the data is produced at source, add a pre-transmission check so what would be rejected externally is caught internally, then replay the pending invoices.
Related area
E-invoicingThese chains are the most common ones, not the only possible ones. Establishing the real cause on your flows, with your messages, is precisely what the diagnostic is for.
An EDIFACT mapping stopped working
What you see
Messages used to go through, now they do not. Often after a partner-side update, sometimes with no identifiable change on yours.
Most frequent causes
- 01
The partner specification changed
frequentA segment became mandatory, a qualifier changed, a field length was reduced. The change is rarely announced in an actionable way.
- 02
A missing segment or qualifier
frequentThe mapping produces a structurally valid message that is incomplete against this particular partner’s expectations.
- 03
Correct data in the wrong place
commonThe value exists and is right, but it sits in a segment the recipient reads differently.
- 04
An upstream coding change
rarerA product or customer master-data overhaul changed the identifiers being sent, without the mapping being adjusted.
What we look at, in this order
- 01The last accepted message and the first rejected one, compared line by line.
- 02The partner specification currently in force, in its present version.
- 03The technical acknowledgement, if there is one: it often names the offending segment.
- 04The other flows to the same partner, to establish the scope.
What the fix involves
Rework the mapping on the identified gap, including the upstream rules that produced the data, test with the partner where available, then replay the pending messages.
Related area
EDI / EDIFACTThese chains are the most common ones, not the only possible ones. Establishing the real cause on your flows, with your messages, is precisely what the diagnostic is for.
The connection passes tests but nothing flows
What you see
The test environment validates, production stays empty. No explicit error — and no invoice reaching its destination either.
Most frequent causes
- 01
An incorrectly registered electronic identifier
frequentThe company is not reachable under the identifier being used, or is reachable under a different one. Transport works perfectly and the document arrives nowhere.
- 02
A gap between test and production
frequentCertificates, endpoints or routing parameters differ between the two environments, often without that being documented anywhere.
- 03
The content does not match the profile
commonThe channel accepts the transport and refuses the document. The difference stays invisible until someone reads the validation response.
- 04
Receiving was never integrated
commonSending works, but nothing comes back into your systems: inbound documents pile up out of sight.
What we look at, in this order
- 01The actual registration of your identifier, and its routing.
- 02The exact configuration difference between test and production.
- 03The profile validation response, as distinct from the transport acknowledgement.
- 04The receiving direction — as often forgotten as it is required.
What the fix involves
Fix the registration and routing, align the production configuration with what was validated in test, bring the content up to the expected profile, then actually wire both directions into your ERP.
Related area
E-invoicingThese chains are the most common ones, not the only possible ones. Establishing the real cause on your flows, with your messages, is precisely what the diagnostic is for.
Our teams re-key data between two applications
What you see
A daily export, an intermediate file, a copy-paste between two applications: the flow "works", thanks to somebody.
Most frequent causes
- 01
Two systems with no interface
frequentThe integration was never done, or was done in one direction only. The re-keying is the bridge somebody built instead.
- 02
Master data not aligned
frequentItem, customer or site identifiers do not match across systems, which makes automatic exchange impossible as things stand.
- 03
Statuses never come back
commonDocuments go out but their lifecycle stays in a portal, forcing someone to look them up and copy them across.
What we look at, in this order
- 01Every double-entry point, recorded and costed in real time.
- 02What each system can already do natively, before writing anything.
- 03The coding gap between the master data involved.
- 04The real frequency and volume, which determine the solution.
What the fix involves
Align the master data, put the exchange in place both ways with error recovery and logging, then remove the manual step — in that order, never the reverse.
Related area
ERP integrationThese chains are the most common ones, not the only possible ones. Establishing the real cause on your flows, with your messages, is precisely what the diagnostic is for.
The logical next step
Fixing one broken process usually reveals another, right next to it.
Your case is not here?
The most expensive symptoms are rarely the best documented. Describe yours and we will come back with a first reading.