Home · Solutions · Supply chain
Solution · Supply chainThe rejection is found on your side of the wire, before the declaration is sent
Customs declarations that clear on the first submission
Robots assemble declaration data from the client's own documents, run the checks that cause most rejections before anything is sent, and turn every response into a task with the field in it.
Executive summary
A truck waits while a broker refreshes a screen. Most of those rejections were visible in the documents.
The flow starts in the mailbox the clients already write to.
A declaration that would have been rejected is stopped inside the office.
your declaration software or the documented national customs channel; the SharePoint case file; the forwarding file in the TMS
Business problem
Customs brokerage
A customs declaration is a data set assembled from documents written for other purposes. The commercial invoice exists so that somebody pays. The packing list exists so that a warehouse can count pallets. The transport document exists so that a driver can prove what was handed over. Nothing obliges the three to agree, and the broker's job is to reconcile them into something the customs system accepts first time.
That reconciliation is invisible work. Weights differ because the packing list counted the pallet and the invoice did not. Line counts differ because two items were consolidated for the buyer. A new consignee has no identifier on file. Codes come from what was used for the same goods last time, usually right and occasionally the reason a declaration is amended a year later.
When a declaration is rejected the consequence lands outside the office: a truck at a border office, a container waiting on release, a client who calls the account manager rather than the desk. Everyone knows rejections happen; nobody can say which three fields cause most of them.
How it works today
Whatever declaration software sits on the desks, this is the route in an agency that grew with its clients.
- PersonA client's file arrives as an email with the invoice, the packing list and the transport document attached
- PersonHeader and line data are typed into the declaration software: parties, values, currency, weights, packages, codes, procedure
- Risk of errorWhere the documents disagree on a weight or a package count, the likeliest figure is taken and the file moves on
- SystemThe declaration is sent, and the broker returns to the screen every few minutes to see what came back
- WaitingA rejection arrives as a code and a message, and the broker works out which data element it means
- PersonThe correction is made, the declaration is sent again, and the client is told it is in hand
- Risk of errorNothing records which client, document or field caused it, so the same cause returns next week
Why the current process costs more than it appears
The budget shows headcount, not what it is spent on.
- Rework is counted as work: a declaration sent three times is three passes through the same screens, and the desk's productivity figures cannot tell it apart from three declarations.
- Waiting is charged to somebody, and at first rarely to the agency: a truck at a border office is the carrier's afternoon this week and the agency's problem at the next tender.
- Nobody owns the causes. A rejection closes the moment it is fixed, so the message, the field and the client behind it leave no trace, and the two clients who send sets that never reconcile are priced exactly like the two who do.
- Experience concentrates in the wrong place: the brokers who read a rejection message and know at once what it means cannot take a week off in September.
Cost of inaction
A truck standing at a border office is absent from every row above. In a model built from salaried minutes, a rejection answered in fifteen minutes and one answered after lunch cost exactly the same; on the ground they do not. For road traffic the entry summary declaration is due one hour before arrival, and a risk-mitigating referral from customs must be answered before the risk assessment resumes.
What compounds is the not-knowing. Rejections are fixed one at a time and counted by nobody, so the agency cannot say whether the same three fields fail every month or whether two clients account for half of them. A file that always gets corrected in the end looks, from the management meeting, like a file that never went wrong.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A Polish customs agency inside a forwarding group: 90 people, eleven of them on declarations across two land border branches and a seaport office; declaration software on the desks, a forwarding TMS beside it, Microsoft 365 E3.
3,100 declarations a month for about 140 regular clients, across import, export and transit; documents arrive as email attachments in a dozen recurring layouts.
A broker opens the invoice, the packing list and the transport document side by side, types the data into the declaration software, sends it and watches for the response.
About 16 minutes per declaration of preparation and rework, blended across a filing that clears first time and one that goes back twice; roughly one in seven is rejected at least once, and no report names the field.
Robots assemble the declaration data set from the client's documents, apply the client's own tariff and procedure rules, and run the checks behind most rejections before anything is sent.
In the modelled case the standard filing is prepared without a keyboard, first-submission acceptance rises because the checks run before the message leaves, and eleven brokers spend the day on classification and on the clients who need talking to. The shape is modelled, not observed.
Proposed solution
The flow starts in the mailbox the clients already write to. A new message opens one case in an Orchestrator queue, attachments are split and classified, and UiPath Document Understanding reads the invoice, the packing list, the transport document and any certificate with them into one data set, keyed to the forwarding file.
The next part is deliberately unglamorous. Before anything is sent, the data set goes through the checks behind most rejections: line values against the invoice total, gross against net weight and against the transport document, package counts and marks, supplementary units, currency and delivery terms, party identifiers, previous documents, guarantee headroom, and every code present on the client's table. A failed check stops one declaration and raises one task.
Classification stays with people, on purpose: where goods are not on the client's table the case is held, a broker decides, and the decision is written back with a name and a date. The clean declaration goes to the channel your declaration software accepts, or as XML against the published specifications of the national customs channel. An acceptance writes the reference into the case file and tells the client; a rejection reopens the case in Microsoft Teams with the message and the field.
UiPath Document Understanding pre-trained Invoices, Packing Lists and Bills of Lading models with Validation Station; UiPath Orchestrator queues, triggers and credential stores; UiPath Integration Service connectors for Microsoft Outlook 365, Microsoft Teams and Microsoft OneDrive & SharePoint; UiPath Action Center tasks in Microsoft Teams
The intake and case model, the extraction configuration for your clients' layouts, the validation battery and its per-client parameters, the classification table and its write-back, submission and response handling, and the clearance board
The hand-off to your declaration software through UiPath Integration Service Connector Builder where it documents an interface, or an XML exchange against the published specifications of the national customs channel
How the automated process works
- AutomationA new message in the client mailbox opens one case; attachments are split, classified and matched to the forwarding file
- AutomationDocument Understanding reads the invoice, the packing list and the transport document, and the fields become one data set
- SystemThe validation battery runs before anything leaves: totals against lines, gross against net and against the transport document, package counts, supplementary units, party identifiers, guarantee, and every code against the client's table
- PersonWhatever fails a rule reaches a broker as an Action Center task in Microsoft Teams, with the field, the two values that disagree and the page behind each
- AutomationThe clean declaration goes to the channel your declaration software accepts, or as XML to the national customs channel, and then waits on a response rather than on a person
- AutomationAn acceptance writes the reference to the case file and the forwarding file and notifies the client; a rejection reopens the case as a task
- AutomationThe clearance board updates through the day: what is lodged, what awaits a response, what came back and on which rule
Human-in-the-loop model
Automation handles
- Reading the client's documents, assembling one declaration data set and keying it to the forwarding file
- Running every consistency, completeness and format check before a message leaves, on every declaration rather than a sample
- Sending, polling for responses, filing the reference and the message trail, and telling the client where the case stands
People decide
- The commodity code for goods the client's table does not cover, and any code a check flags as inconsistent
- The customs procedure, the valuation, and whether a case is corrected, withdrawn or lodged again
- What to do with a rejection whose cause sits in the client's documents rather than in the filing
- The rules themselves: tolerances, per-client parameters and the classification table stay owned by the head of customs
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- client documents by email
- the client's classification and party table
- the forwarding file reference in the TMS
- responses from the customs channel
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Document Understanding
- UiPath Integration Service
- UiPath Action Center
Target systems
- your declaration software or the documented national customs channel
- the SharePoint case file
- the forwarding file in the TMS
Human touchpoints: Action Center tasks in Microsoft Teams; Validation Station for documents that cannot be read cleanly; the clearance board in the desk's Teams channel
Technologies used
pre-trained Invoices, Packing Lists and Bills of Lading models read the commercial set; Validation Station for low-confidence fields
Aone case per declaration; rules, submission, response polling, retries and audit
Amailbox intake, case file, Teams posts, declaration-channel endpoint
Avalidation and rejection tasks decided where the broker works
Athe case file: documents, data set sent, messages back, retained
Athe clearance board: lodged, awaiting response, rejected, by cause and client
Athe documented Polish channel for AES, AIS and NCTS2: two-way XML against published XSD, with a test environment
BIllustrative economic model
What it is worth, with the arithmetic shown.
A rejection is not priced here as an event: no credible institutional figure exists for what one costs, and inventing one would be the quickest way to make this page untrue. What is priced is desk time, sixteen minutes per declaration blended across a filing that clears first time and one that goes back twice, at an illustrative €26 an hour for a customs desk role in Poland. The one-in-seven rejection share belongs to this scenario.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- A declaration that would have been rejected is stopped inside the office, where correcting it costs minutes rather than an afternoon at a border office
- Desk capacity stops being set by document quality: peaks are absorbed by queue throughput, and brokers' hours go to cases that need judgement
- Clients are told where a case stands without asking, and the account manager stops being the fastest route to an answer the system holds
- A new client is set up as configuration, so an unfamiliar document set is not a training exercise for eleven people
- Rejection causes become a ranked list, which turns a conversation about document quality with a client into an evidenced request
The management view
- Rejections stop being anecdotes: which rule, which client, which document, how often, and how long each held a case open
- Capacity is visible before it becomes a problem: what is lodged, what waits on a response, what is open past the promised window
- Knowledge that lived in two brokers' judgement becomes a table with an owner and a history, and peak season stops being a staffing risk
- The cost of processing a client becomes attributable to that client, which is what makes a price defensible
Board-level KPIs
Security and governance
Control is not an add-on.
- Robots reach the client mailbox and the case file under service identities scoped to the one mailbox and the one library they need, while the identity used to submit is separate again, with its secret in a credential store rather than inside a workflow
- Each declaration keeps its file: documents received, data set sent, every message back and the rules version that decided it, under a Microsoft Purview retention label
- Validation rules, tolerances and the classification table are versioned and owned by the head of customs, and each run records which version applied
- Documents, tasks and rules stay in your Microsoft 365 tenant, and the robots run from the EU region of UiPath Automation Cloud
Why now
The filing window is short and published. ICS2 has been operational in all Member States for all means of transport since 1 September 2025, with limited temporary derogations, and for road the entry summary declaration is due one hour before arrival. A desk that finds its own errors before submission works inside that hour. Priced as salaried work, preparation and rework model out at about €21,500 a month.
The state side of this landscape is its best documented part: Poland's customs systems are reachable through PUESC SEAP as two-way XML against published XSD specifications, with a test environment, which is the difference between an integration and a screen-scraping project.
The message layer keeps moving: NCTS Phase 5 had a deployment deadline of 2 December 2024 and Phase 6 an initial target of 1 September 2025, with derogations carrying deployments into June 2026.
Relevant executive roles
The agency sells a filing that clears, and today that promise rests on the attention of whoever has the file open
Rejection causes become a ranked list rather than a feeling, and peak season stops depending on two people not taking leave
Rework is capacity the agency already pays for and never bills; the model puts a number on it, and the case file makes a filing defensible years later
Common questions and objections
Nor would we design it that way. The automation applies the code table your head of customs owns and holds the case when goods are not on it; a broker decides, and the decision goes back into the table.
It validates the message. Most rejections start in disagreement between the documents the message was built from, which the software never sees because a broker resolved it in their head before typing. Those checks run here, before the data set exists.
Then the other half is where we start. Recurring layouts are read by the models, the rest go to Validation Station, which still beats reading three PDFs side by side.
When this is not the right solution
- Fewer than roughly four hundred declarations a month, where a disciplined desk and a written checklist cost less than a rules layer and its upkeep
- A client base that already sends structured data the desk imports without touching, where the value sits in response and exception handling alone
- No documented way for your declaration software to accept a prepared data set and no appetite to build against the national channel; the checks still pay, but the filing stays manual
A question for the next management meeting
Which three fields caused most of our rejections last quarter, and if no report in this agency can answer that, what are our brokers actually correcting?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- Extraction configured for your clients' invoice, packing list and transport document layouts, with Validation Station for what cannot be read cleanly
- The pre-submission validation battery, its tolerances and per-client parameters, replayed against filings rejected in the past
- The classification table with an owner and a history, submission and response handling, the case file under retention and the clearance board in your Teams channel
- A pilot on one branch and one procedure, then rollout with hypercare and a runbook for the brokers
We need from you
- Three months of declarations with the documents they were built from and the responses that came back
- A named head of customs who can decide tolerances, codes and what a failed check must do
- Technical access to your declaration channel, its test environment and the client mailbox
- Your client list with the document set each one sends, including the two that never reconcile
Stages
Discovery
One month of filings and responses read end to end: procedures, document sets, rejection causes
Rules
The validation battery, tolerances and per-client parameters written with your head of customs
Build
Intake, extraction, the rules layer, submission and response handling, Teams tasks and the board
Parallel run
Declarations prepared alongside the manual ones and compared field by field before anything is sent
Go-live
One branch and one procedure first, then branch by branch, with hypercare and a weekly rules review
Departmental. Effort follows the number of procedures in scope, how many client document layouts must be read reliably, and how your declaration channel accepts a data set.
Every rejection gets fixed. Not one of them gets counted.
Send us one month of your filings: procedures, the rejections with their error messages, and whose documents they came from. We return a ranked list of the causes a pre-submission check would have caught, and the two we would build first.
Find the fields behind your rejectionsThe neighbouring process usually has the same problem
Your ERP holds every figure the customs pack needs. Somebody types them in again anyway.
View solution Supply chainMonitored carriage notified before the truck movesA dispatcher decides what is monitored, types the notification and hopes nobody swaps the trailer.
View solution Supply chainEvery proof of delivery on file before the invoice is dueFreight is delivered, invoiced and disputed before anyone finds the signed document.
View solutionIndustries we deliver this in most oftenTransport & logistics