What people ask before handing us a flow

Preparing the file before it enters your TMS. We ingest customs documents as they arrive, reconcile container numbers, gross weights, HS tariff codes and IncoTerms field by field against your order data, then push a validated payload into CargoWise. It is not a customs brokerage service: we file no entry on your behalf.

Scans, faxes, native PDFs and photographs of paper documents, in any language and any layout. The file enters the pipeline as it arrives: there is no per-shipper template to define and no format to impose on your partners. An unreadable document is flagged as an exception rather than pushed through with doubtful data.

They are order-of-magnitude estimates meant to frame the problem, not measurements taken in your operation — the pre-clearance page says so next to the figures. The 100-shipment benchmark exists for exactly that reason: it replaces our estimate with your own durations, on your own files.

The pipeline described on this site pushes into CargoWise, through its native eAdaptor and Universal eXchange APIs. For another TMS, what changes is not the document parsing but the integration surface your system exposes. Tell us which one you run in the first conversation: we would rather answer on your environment than in general.

It is flagged before the push, not after the entry has been filed. A net weight on the packing list that does not match the gross weight on the bill of lading comes back as a discrepancy, and your operators review only those cases. That shift is where the gain comes from: the re-keying disappears, the human judgement stays.

The mechanism is the same: produce correct data, transform it into the expected structure, transport it, handle the responses. What changes is the format and the counterparty — a UniversalShipment payload into CargoWise rather than an EDIFACT message to a trading partner. A team that can read an EDIFACT rejection can read a customs discrepancy.

Describing your problem, in a few lines. We come back with a first reading and, if the subject is in our field, we scope a diagnostic. We never start with a software proposal.

It depends how many systems are involved. A single failing flow is usually days, not weeks. A scope covering several partners and several applications takes longer. We give an estimate after the first conversation, before starting.

Not for the first conversation. For the analysis, read access to the rejected messages and exchange logs is enough in most cases. We state exactly what we need, and why.

No. The map and the remediation plan are yours, including if you choose to have the fixes carried out in-house or by another team.

Usually not. Most failures come from the mapping, the transformation or the upstream data, not the tool. If replacement genuinely becomes the best option, we say so after the diagnostic — not before.

Yes — that is most of our work. We start from the rejected message and the expected specification; the development history is useful but not required to find the gap.

Yes. We regularly work alongside an incumbent team on a specific flow they cannot address in time, and coordinate with them when a change has to be made on their side.

It happens: the flow works, but a business rule or an upstream piece of data is wrong. That is a useful result in itself, and we say so plainly rather than hunting for a technical problem that does not exist.

No. We work on the technical implementation: mappings, data transformations, connectivity, integration. On interpreting the rules and your own obligations, your legal or tax advisers remain the reference.

Mainly Francophone West Africa, plus cross-border flows within the UEMOA zone. We work in French and English.

Yes, and they overlap heavily. An e-invoicing flow rests on the same mechanics as EDI: produce correct data, transform it into the expected structure, transport it, handle the responses.

Those whose exchanges are standardised and high-volume enough that an error costs real money — typically mid-sized industrial, logistics and distribution businesses. The criterion is not headcount, it is flow complexity.

Because a price published before a diagnostic would be invented. What an engagement costs depends on the number of systems involved, the number of partners affected and the state of the existing documentation — three things nobody knows before looking. We quote after the diagnostic, against a written scope.

Fixed price against a defined scope, where the diagnostic has allowed that scope to be pinned down precisely. Time and materials where the scope stays open — typically ongoing support or taking over poorly documented flows. The basis is agreed before we start, never partway through.

The first conversation is not: it exists to locate the problem and check that it is our field. The full diagnostic — flow mapping, message analysis, costed remediation plan — is a piece of work in its own right, billed and deliverable independently of whatever follows.

The determining factor is not invoice volume but the number of systems and partners involved. A single failing flow to one recipient sits in a very different order of magnitude from a scope covering several applications and several customers. We give a range in the first conversation, before any commitment.

No. No subscription, no minimum term. Ongoing support exists for companies that want it, but it is decided after a first successful engagement, never before.

The first conversation usually happens within days of your request. For a completely blocked flow we try to bring it forward — a stopped flow has a daily cost, and a week of slippage shows up in the cash position.

A failing mapping to one partner is usually days to two weeks, testing included. A stalled onboarding takes longer, because part of the elapsed time depends on responses from the provider or the partner. A full ERP integration is measured in weeks. The estimate comes after the diagnostic, not before.

We prioritise what unblocks the flow and explicitly defer what can wait. An ordered remediation plan always states what is handled now, what comes next, and what is not worth handling at all.

No. We need one contact able to validate test cases and go-lives, plus access to the technical material. Between those points most of the work happens on our side. The method page sets out what is expected at each phase.

The minimum necessary. For the first conversation, the symptom and one rejected message are almost always enough. For the analysis, read access to the messages and exchange logs covers most cases. We state exactly what we need, and why.

They are treated as confidential, used solely for the engagement and deleted at its end, unless the contract requires otherwise. We ask you to limit the personal data you send and to pseudonymise it where possible.

Not to diagnose. Read access is enough in the large majority of cases. Write access only becomes necessary during remediation, on a defined scope and under your own security rules.

Yes, without difficulty, and before any technical exchange if you prefer. It is a routine request in this field and it does not delay the start.

A flow we delivered that fails for the same cause is fixed at no further charge. A failure caused by an external change — a new partner specification, a change in your ERP — is new work, but on a scope we already know.

That is precisely what we try to avoid. Every delivery is documented, and a knowledge transfer is offered so your team can read a rejection, fix the common cases and know when to escalate.

Yes, where flow volume or criticality justifies it. It is designed around what actually fails in your environment: alerts that only fire when someone can act, and a clear view of what was sent, what is stuck and what failed.

For a completely stopped flow, yes, as far as our availability allows — and we say so plainly when we cannot meet the timescale. A responsiveness commitment we could not honour would be worse than a refusal.

On the constraints we observe, and on nothing else. We sell no platform and take no commission on the ones you use or that we might mention. When we say a replacement is unnecessary — which is usually the case — we lose nothing by saying it.

With the flow costing the most today, taken all the way to production, rather than several flows handled halfway. One flow in production teaches more about your real constraints than several months of analysis.

We say so. It happens that a flow works correctly and a business rule or a value entered upstream is the real cause. That is a useful result, and reporting it beats hunting for a technical problem that does not exist.

With them where they are available, instead of them where they are not. Either way we document what we deliver: a flow your team cannot maintain without us is a flow half delivered.

Because fixing a flow means following it end to end, and that traversal almost always reveals manual work that no longer needs to exist: re-keying, reconciliation, double-checking. We report it; you decide whether it is worth addressing.

No. A proposal starts from something observed in your environment, with evidence. If we find nothing, we propose nothing — and we say so.

That is what we recommend. We take the flow costing you the most today, put it into production, and decide the rest with results in hand rather than with a multi-year plan.

Often they can, and we say so when that is the case. The question is not competence: it is the learning time on a format they may never see again, and what that time costs compared with a specification written by someone who has done it before. If the gap is narrow, do it in-house — we would rather say that early.

That is a reasonable answer, and sometimes the right one. We add only one thing: a failing flow does not stabilise on its own, and its cost is monthly. If you know what your current rejections cost you, you can decide with your eyes open. If that figure does not exist, the decision is being made blind — and that is the only point we press.

Then it probably is not the moment, and we would say so too. Working while another team is changing the same flows produces conflicts that are expensive to untangle. Waiting for the current project to land beats starting against an unstable scope.

Our clients work in a small sector where names travel fast; we do not publish them without written agreement, and many do not give it. What we can do instead is more useful: bring a rejected message to the first conversation and we will tell you what it reveals. That is verifiable on the spot, which a list of logos is not.

A fair question, with a two-part answer. First, we host nothing and operate nothing on your side: if we disappeared, no flow stops. Second, every delivery is documented so your team or another supplier can pick it up. Our size would be a risk if we created a dependency; we build the opposite on purpose.

That is common, and the failure rarely comes from the teams. It comes from too broad a scope opened at once, or from an analysis never tested against a go-live. We take one flow, one recipient, all the way into production. If it does not work there, it will not work better across ten.

Then the useful question is not what the work costs but what waiting costs. The first conversation consumes no budget and lets you put a figure on both. If the cost of waiting is lower than the cost of the fix, waiting is the right call — and we will tell you so.

Understandable on interpreting the rules, which is not our field anyway: your own advisers remain your reference. But the technical part does not depend on that timetable. An incorrect mapping, a badly registered identifier or a refused export are wrong regardless of the dates, and fixing them does not become obsolete when those dates move.