What Happens in the First Second After Your File Arrives >> L5 Series,Part 2
You press send. A moment later you get an error code and one line of text. That line is the end of a process, not the whole of it. Your file passed through a series of gates inside the national hub, and it stopped at the first one it failed. Knowing the order of those gates tells you a lot about why your project keeps stalling.
Here is what happens, in order.
Gate 1: who are you
Before the hub reads a single serial number, it checks the sender. Certificate, token, or API key. Is it valid, is it still active, and does it belong to a company registered on the platform.
Most companies pass this gate once and never think about it again. Then the certificate expires and everything stops on a Thursday afternoon.
Gate 2: can the file be read
The hub tries to parse what you sent. Valid XML or JSON or CSV, correct encoding, no broken characters, file size within the limit.
This gate catches the obvious failures. It is also where large files quietly die, because a file that is too big is often rejected before anything inside it is looked at.
Gate 3: does the structure match
Now the hub compares your file against its schema. Required fields present, fields in the expected place, values in the expected shape.
Note the difference from gate 2. A file can be perfectly valid JSON and still fail here, because the hub wanted a field you did not send.
Gate 4: are the identifiers real
The hub checks each identifier on its own terms. GTIN check digit, SSCC length, date format, application identifier structure, EPC syntax.
Nothing is compared to a database yet. This is pure arithmetic and pattern checking. It is fast and it is the last gate that does not need to know anything about you.
Gate 5: do we know this product and this company
This is where files start failing for reasons that surprise people.
The hub now looks up what you sent. Is this GTIN registered on the platform. Is it registered to your company. Is the product licensed and in an active state. Is this GLN a known location. Are you authorised to report for it.
Everything above gate 5 is technical. From gate 5 down, it is regulatory. Your file can be flawless and still be rejected because a product registration was never completed, or because the GLN of your third party warehouse was never added.
Gate 6: does this event make sense
The hub checks your event against the history it already holds.
Does this serial number exist. Was it already commissioned. Was it already decommissioned. Are you shipping something you never received. Are you aggregating a pack that is already inside another case. Is the event date in the future.
This is the hardest gate to pass consistently, because passing it depends on everything you sent before. A single missing shipment event from last month will cause receiving events to fail for weeks, and the error message will point at today's file.
Gate 7: write and answer
Only now does the hub store your data and send back a response.
Some hubs answer here in real time. Others acknowledge receipt at gate 2 and run gates 5 and 6 later in a queue, which is why a file can be accepted on Monday and rejected on Wednesday.
Why you only ever see one problem
The hub stops at the first gate you fail. It does not keep going to tell you what else is wrong.
So you fix the error, resubmit, and hit a different error. Fix that one, resubmit, hit a third. Teams often read this as an unstable platform. It is not. You are walking down a ladder, one rung at a time, and each rung was always there.
The way out is to run the same checks yourself, in the same order, before you send anything.
Why the same file passes in one country and fails in another
Gates 1 to 4 are close to identical everywhere. They are technical, and the standards behind them are global.
Gates 5 and 6 are where countries differ, because that is where national rules live. One country requires product registration before any event. Another accepts the event and flags the registration later. One country rejects an event that arrives out of order. Another holds it and waits for the missing one.
This is why a working integration in one market gives you less of a head start in the next market than you expect. The technical layer travels. The regulatory layer does not.
What to do with this
Build your own validation in your L4, in this exact order, and stop the file at your end.
The cheap wins are gates 5 and 6. Keep your own copy of registered GTINs and GLNs and check against it before submission. Track the state of every serial number you have reported, so you can catch an impossible event before the hub does.
Most companies validate structure carefully and validate state not at all. That is backwards. Structure errors are found in testing. State errors are found in production, with stock waiting.
Next in this series
Part 3: master data, the gate that stops more projects than any technical problem.