EDI 856 and the advance ship notice: the segments, the timing rule, and what a bad ASN costs
A segment-level guide for the people who build the 856, transmit it, and get charged when it is wrong: the HL hierarchy, the fields retailers score, the timing rule most teams miss, and how to catch a bad ASN while the freight is still moving.
What an ASN is
An advance ship notice (ASN) is an electronic message the shipper sends to the receiver before the freight arrives, listing exactly what is on the truck: which purchase orders, which items, which quantities, packed inside which cartons, stacked on which pallets. In EDI, the ASN is transaction set 856.
It exists because of receiving labour. A distribution centre that knows what is coming can schedule the door, staff the shift, and receive by scanning a carton label instead of opening cartons and counting units. That is the trade being made. The receiver gives up manual verification, and in exchange your 856 becomes the receiving document.
The consequence is worth stating flatly. The retailer does not receive what is on the truck. The retailer receives what your 856 said is on the truck, and then checks the truck against it. Every discrepancy is therefore attributed to you by default, discovered at their dock, on their clock, and priced by their vendor compliance program.
An ASN is not a bill of lading, which is the carrier contract. It is not a packing list, which is the paper in the pouch. It is not an invoice, which is the 810. It overlaps all three and replaces none of them. What makes it different from every other document in the flow is that the receiver acts on it before anyone has verified it.
The 856 is the only document you send where the receiver's system trusts you first and audits you second. That asymmetry is the entire reason ASN accuracy is scored and penalized the way it is.
Where the 856 sits in the document flow
The 856 is one document in a chain, and most ASN defects are inherited from the document upstream of it rather than created in the 856 itself.
850
Purchase order
855
PO acknowledgement
940
Warehouse shipping order
not from here
945
Warehouse shipping advice
generate from here
856
Advance ship notice
810
Invoice
A typical retail flow runs like that. The customer sends an 850 purchase order. You confirm it with an 855. If a third-party warehouse is picking, you issue a 940 warehouse shipping order and they return a 945 warehouse shipping advice telling you what was actually built and loaded. You transmit the 856 to the customer before the truck arrives. You invoice with an 810. Along the way the carrier feeds you 214 status messages, which are a different document with a different sender.
One structural note before the document itself. The 856 must be generated from the shipping confirmation, not the pick instruction — from the 945 a third-party warehouse returns, or the shipment record in your own WMS. The EDI integration page makes the general case for why the 945 is the most under-used document in most EDI estates; what matters here is the consequence for one document, which is that an 856 built at order release is a statement of intent wearing the costume of a statement of fact.
On who sends it: the ASN comes from the party that ships the goods, not from the carrier. If a 3PL physically ships on your behalf, the 856 is still yours under the trading partner agreement even when the 3PL transmits it using your sender ID. Compliance liability sits with the vendor of record. The 3PL's 945 does not go to your customer.
This page is about one document. Partner onboarding, mapping, transport choice between VAN, AS2 and SFTP, acknowledgement architecture and cost live on the EDI integration page, and everything below assumes that layer already exists.
If your 856 is generated at order release rather than at shipment confirmation, every other fix on this page is cosmetic. Fix the trigger first.
Five nodes · four pointers
The hierarchy is the hard part
An 850 is a flat list. An 856 is a tree, and the tree is where implementations break.
The BSN segment declares which shape the tree takes. BSN05 carries a hierarchical structure code telling the receiver's parser what levels to expect and in what order. The one you meet most in retail is 0001 — Shipment, Order, Packaging, Item — and the word doing the work there is Packaging, because that single declared level covers both the pallet loop (HL03 = T) and the carton loop (HL03 = P). A pick-and-pack 856 with pallets in it is still a 0001 tree; it just has two packaging tiers instead of one. The flatter Shipment, Order, Item shape is used where cartons are not individually identified, and it carries a different code.
Your partner's implementation guide names the exact code they accept and which HL03 levels are mandatory beneath it. It is not negotiable and it is the first thing to look up, because a tree that is legal under one code is a reject under another.
Every node in the tree is an HL segment with four elements that do all the work. HL01 is a sequential ID starting at 1 and never reused inside the transaction set. HL02 is the HL01 of this node's parent, and it is blank only at the top. HL03 is the level code: S for shipment, O for order, T for tare or pallet, P for pack or carton, I for item. HL04 is a child flag, 1 if something nests below this node and 0 if nothing does.
Here is a minimal, correctly balanced 856 with one order, one pallet, one carton and one item.
ST*856*0001~BSN*00*ASN10023*20260824*1840*0001~HL*1**S*1~TD1*CTN25*1~TD5**2*XPOL*M~REF*BM*558830147~DTM*011*20260824~N1*ST*RETAIL DC 42*UL*0012345000041~N1*SF*ACME MFG*92*ACME01~HL*2*1*O*1~PRF*5583001***20260803~HL*3*2*T*1~MAN*GM*000123450000000010~HL*4*3*P*1~MAN*GM*000123450000000027~HL*5*4*I*0~LIN**UP*012345678905*VN*SKU-4410~SN1**24*EA~PO4*24*12*OZ~CTT*5~SE*21*0001~
HL*1**S*1~
Shipment. No parent — HL02 is blank only here.
TD1*CTN25*1 TD5**2*XPOL*M · REF*BM DTM*011 · N1*ST N1*SF
HL*2*1*O*1~
Order. HL02 points at node 1, the shipment.
PRF*5583001
HL*3*2*T*1~
Pallet. HL02 points at node 2, the order.
MAN*GM*000123450000000010
HL*4*3*P*1~
Carton. HL02 points at node 3, the pallet.
MAN*GM*000123450000000027
HL*5*4*I*0~
Item. HL02 points at node 4, the carton — not at the order.
LIN**UP*012345678905 · SN1**24*EA · PO4*24*12*OZ
CTT01 = 5 HL segments · SE01 = 21 segments ST→SE · HL04 = 0 on the item because nothing nests below it.
THE SAME TREE · ONE ELEMENT CHANGED
HL*5*2*I*0~ ← was 4
One digit. The item now hangs off the order instead of the carton. Segment count unchanged, so SE01 is still 21. HL count unchanged, so CTT01 is still 5. The file balances, your translator passes it, and the 997 comes back accepted. The receiver simply cannot tell which carton the 24 units are in, and finds that out at the door.
The 21-segment file above, drawn as the tree it describes. Every arc is an HL02: a pointer to a parent's HL01, not an indent. The indent is our drawing. The pointer is the file — which is why a tree can be perfectly legal and completely wrong.
Five things in that fragment are worth checking against your own output.
HL02 on the item loop points at 4, the carton, not at 2, the order — so the retailer can tell which carton the units are in. HL04 on the item is 0 because nothing nests below it.
TD102 is 1 because this fragment carries one carton. On a real 412-carton load TD102 is 412 and there are 412 pack-level HL loops, and the two get checked against each other. Read your partner's guide on what TD102 counts before you assume cartons — a minority of programs count handling units.
CTT01 is 5: the number of HL segments in the transaction set, not the number of line items. It is the classic first-implementation reject.
SE01 is 21, every segment from ST through SE inclusive. A translator computes this for you. If you generate 856s from a template or a hand-rolled writer, it is the element that goes off by one the first time somebody adds a conditional REF.
And the identifiers are real. Both MAN02 values are valid SSCC-18s and N104 is a valid 13-digit GLN, check digits included. Run them through a calculator — that is why they are printed. Retailers validate check digits, and a scanner will not read a barcode whose check digit is wrong no matter what the 856 says about it.
The tree can also be structurally legal and semantically wrong. An HL04 of 1 with nothing beneath it, a parent pointer aimed at the wrong node, a pack loop whose contents do not add up to what the shipment level claims: all of that parses. Your translator will pass it. The 997 will come back accepted. The error surfaces at the receiver's dock.
The 856 segment by segment
This is the reference table. Levels are given as S for shipment, O for order, T for tare, P for pack, I for item. Element positions follow ANSI X12 004010, which remains the version most North American retail programs mandate, but your partner's implementation guide is the authority on which segments and qualifiers are mandatory for your account.
Two segments in this table carry most of the money. PRF at order level is how the receipt gets matched to a purchase order. SN1 at item level is the quantity you are asserting shipped, and it is the number you are measured against at the door. Everything else can be right and those two wrong, and you will still be charged.
| Segment | Level | What it carries | Elements that matter | How it fails |
|---|---|---|---|---|
| ST | Envelope | Transaction set header | ST01 = 856; ST02 control number, must equal SE02 | Mismatched ST02 and SE02 rejects the whole transaction set at the 997. |
| BSN | Header | Purpose, ASN number, date, time, hierarchy declaration | BSN01 purpose (00 original, 05 replace, 07 duplicate, 01 cancel); BSN02 shipment ID; BSN03/04 date and time; BSN05 hierarchical structure code | Resending a correction as 00 instead of 05 creates a duplicate shipment in the receiver's system. BSN02 must be unique forever, per partner. |
| HL | All | The hierarchy itself | HL01 sequential ID; HL02 parent's HL01; HL03 level code S/O/T/P/I; HL04 child flag 1 or 0 — optional in the base 4010 standard, mandatory in essentially every retail guide you will be handed | Wrong parent pointer, or HL04 = 1 with no children below. The file parses; the tree is wrong. |
| TD1 | S | Packaging type and total lading quantity and weight | TD101 packaging code (CTN25, PLT94); TD102 lading quantity; TD106/107/108 weight qualifier, weight, UOM | TD102 that disagrees with the number of pack-level HL loops. Usually the first thing a compliance report picks up. |
| TD5 | S | Routing: who is hauling it and how | TD502 = 2 with TD503 SCAC; TD504 method (M motor, LT LTL, A air, R rail) | A SCAC the receiver's appointment system does not recognize, or one that does not match the carrier at the gate. |
| TD3 | S | Equipment: trailer or container type and number | TD301 equipment code (TL trailer, CN container); TD302/303 initial and number | Trailer number that does not match the seal record. Slows the door and invites a manual receipt. |
| REF | Any | Reference numbers, one per segment | REF01 qualifier + REF02 value. BM bill of lading, CN carrier PRO, PK packing list, DP department, IA vendor number | The guide mandates specific qualifiers at specific levels. Right value at the wrong level is still a reject. |
| DTM | S | Dates | DTM01 qualifier (011 shipped, 017 estimated delivery, 067 current scheduled delivery); DTM02 CCYYMMDD | A ship date later than the transmission timestamp, or an estimated delivery that contradicts the booked appointment. |
| N1 loop | S, sometimes O | Parties: ship-to, ship-from, mark-for | N101 entity code — ST ship-to, SF ship-from, BT bill-to, BY buying party. Mark-for is partner-specific: some guides use a dedicated mark-for entity code at order or pack level, others carry the store number in a REF instead. N103 qualifier (UL for a GS1 GLN, 92 buyer-assigned, 9 DUNS+4); N104 the ID | A ship-to that is not the DC on the PO. On multi-store loads the mark-for identifies the store, not the DC, and it belongs at the level your guide says it does — putting it at shipment level on a multi-store trailer tells the receiver every carton is going to one store. |
| PRF | O | The purchase order reference | PRF01 PO number; PRF04 PO date | Nothing else on the document matters if this is wrong. A bad or missing PRF01 means the receipt cannot be matched to an order at all, so the goods land as unallocated inventory and the invoice stalls behind them. |
| MAN | T and P | The SSCC-18 printed on the physical label | MAN01 = GM; MAN02 = the 18-digit SSCC | Any drift between MAN02 and the GS1-128 barcode on the carton makes that carton unscannable at receiving. |
| PO4 | I (pack level in some guides) | Physical details of the pack | PO401 pack; PO402 size; PO403 UOM; PO406 gross weight per pack | Usually cosmetic, until a partner scores cube and weight accuracy for slotting and trailer planning. |
| LIN | I | Item identification as qualifier and value pairs | UP consumer UPC (UCC-12), UK the 14-digit shipping container code, EN EAN/UCC-13, VN vendor item, IN buyer item, SK SKU | Sending only your vendor number when the guide requires the buyer's item number. Everything else is right and the line still will not match. |
| SN1 | I | The quantity claim | SN102 units shipped; SN103 UOM; SN105 quantity ordered | The field you are audited against. SN102 is what you assert shipped; the count at the door is what actually shipped; the gap between them is the deduction. |
| SLN | I | Sub-line detail for prepacks and assortments | SLN quantities and item IDs beneath the parent LIN | Prepacks flattened to a single line, so the receiver cannot break the assortment into sellable units. |
| CTT | Summary | Transaction totals | CTT01 = number of HL segments in the transaction set, not line items; CTT02 optional hash of SN102 values | Counting line items instead of HL segments. The classic first-implementation reject. |
| SE | Envelope | Transaction set trailer | SE01 = segment count including ST and SE; SE02 must equal ST02 | Off by one. A translator recomputes SE01 for you; hand-rolled writers and template-generated files do not, and they drift the first time a conditional segment is added. |
Same document, different alphabet
If your mandate is EDIFACT, this is a DESADV
Everything above is ANSI X12, which is what a North American retail or 3PL mandate means in practice. Trade into a European retailer and the same business document arrives as an EDIFACT DESADV. The concepts survive the translation. None of the segment names do.
Consignment Packing Sequence — own sequence number plus its parent's. Same parent-pointer idea, different expression.
Two consequences worth planning around. If you run both, you are maintaining two expressions of one business object, and a defect fixed in one does not fix the other — teams routinely discover this when a quantity bug is patched in the 856 generator and keeps shipping on the DESADV for another month.
And everything on this page about timing, quantity truth and label-to-document agreement applies unchanged, because those are not X12 failures. They are ASN failures. Only the element names move.
Timing: the 856 has to beat the freight
Two ASNs can carry identical, perfect data and only one of them is compliant. The difference is when it landed. The rule every program reduces to is that the 856 must be transmitted, delivered and processed before the goods reach the receiving door.
Programs express it differently. Some require transmission within a fixed window of the trailer departing, commonly measured in minutes to a few hours. Some require the file a set number of hours before the scheduled appointment. Some just say before arrival and then measure it against their own gate timestamp. Your routing guide has the exact wording and it is the only version that counts.
What catches people is that transmit time is not arrival time. Yours is a line in your translator's log. Theirs is when their gateway collected the file and their application finished importing it. Between the two sits a VAN mailbox poll interval, an AS2 retry, and a batch import that may run every thirty minutes. You are graded on their clock, not yours.
The lanes that cannot be compliant
Short lanes are where this becomes structural rather than occasional. A regional delivery with ninety minutes of transit does not survive an hourly ASN batch on your side plus a thirty-minute import on theirs. The data will be immaculate and the file will still be late. That is not a mapping defect and no amount of validation will find it, because nothing about the document is wrong.
The same clock governs corrections. If the load is re-tendered, cut, or rebuilt after you transmitted, the replacement 856 with BSN01 = 05 or the cancellation with BSN01 = 01 has to land before arrival too. A correction that arrives after the receipt is closed is not a correction. It is a dispute.
transit time < your batch cycle + their import cycle
When that is true the lane cannot be compliant on a schedule. Move it to event-triggered transmission at dock departure, or stop agreeing to the window.
If a lane's transit time is shorter than your ASN batch cycle plus your partner's import cycle, you do not have a data problem, you have a schedule that cannot be compliant.
How ASNs actually fail, and what each failure costs
Six failure modes, grouped by where they actually get fixed — because they get fixed in four different places: the file generator, the label printer, the schedule, and monitoring you probably do not have.
That last one deserves emphasis. A rejected file at least told you something. A file that never arrived tells you nothing, and it is the only failure on this list where the first notification you receive is a chargeback.
| Failure | What it looks like | What it costs |
|---|---|---|
| Hierarchy mismatch | HL04 claims children that do not follow, a parent pointer aimed at the wrong node, or pack loops that do not sum to TD102 | Rejected by the partner's application if you are lucky, which produces an 824. Received and reconciled against you if you are not. |
| Missing or wrong PO reference | PRF01 carries your internal sales order number, or the order-level HL is absent entirely | The receipt cannot be matched. Goods land as unallocated inventory and the invoice stalls behind them. |
| Quantity disagreeing with what shipped | SN102 built from the pick instruction rather than the shipping confirmation | Shortage or overage recorded against you, invoice short-paid, ASN accuracy score falls for the period. |
| Late transmission | Data is correct; the file lands after the trailer | Full ASN penalty on an otherwise clean shipment. The most avoidable failure on this list. |
| Label and SSCC mismatch | MAN02 does not match the GS1-128 on the carton, or two cartons carry the same SSCC | The carton will not scan. Receiving falls back to manual, which usually adds a handling charge on top of the ASN violation. |
| Missing 997 | You transmitted, nothing came back inside the agreed window, and nobody was watching the window | You cannot tell from your side whether the 856 never landed or the acknowledgement was lost coming back, and you have to assume the worse one. Either way the first thing that tells you is a deduction, weeks later, and by then the shipment has been received manually and priced accordingly. |
Every validator in the chain was checking whether the file was legal
Nothing in a typical ASN failure is broken. The translator does its job, the 997 comes back clean, the truck arrives on time. The defect is not in the file — it is between the file and the warehouse record, and no layer in the path holds both.
Which is why the failure below is discovered at a retailer's dock rather than at any point in your own stack, and why the deduction arrives on a remittance advice a full payment cycle later.
One truck, three POs, two cartons that do not exist
A consumer goods supplier loads a single trailer for one retail DC: 412 cartons on 14 pallets, covering three purchase orders. The ASN is generated automatically when the shipment is released in the ERP, which is to say it is built from the pick instruction.
On one PO, a line is ordered as twelve cartons of 24 units. Two cartons' worth of stock fails QC on the line and is pulled. Ten cartons go on the truck. The warehouse records it correctly in the WMS and the shipping advice reflects ten. The 856 does not, because the 856 was built two hours earlier from the release. It carries twelve pack-level HL loops, twelve SSCC-18 numbers in MAN02, and SN102 asserting 288 units.
Everything downstream behaves exactly as designed. The translator validates the file: balanced, legal, counts correct. It transmits at 18:40. The 997 comes back accepted at 19:05. The trailer arrives at 06:40 the next morning, well after the ASN. On paper this is a compliant shipment.
Receiving scans SSCC labels against the ASN. Ten cartons scan clean. Two SSCC numbers on the 856 have no carton behind them, because those cartons were never built. The receipt closes 48 units short against a document that claimed them.
No single number — which is the point. You will not see any of it until the remittance advice.
An ASN accuracy violation is logged for the quantity variance. Two missing-carton investigations are opened, which many programs bill as their own research or handling charge. The 810 invoices 288 units against a receipt of 240, so it is short-paid and a deduction is raised. The month's ASN accuracy score drops, and if the account was already near the threshold, that single shipment moves the scorecard rather than just adding a fee.
Nobody at the supplier learns any of this until the remittance advice for that invoice arrives — a full payment cycle later, which on net-30 or net-60 terms means the conversation happens one to two months after a Tuesday morning in August, in the form of deduction codes nobody can immediately tie back to anything.
The fault is not the QC pull. Stock fails QC. The fault is that between the pick instruction and the transmitted 856 there was no gate comparing the document to what the warehouse actually confirmed, and the two records lived in systems that never spoke. Every validator in the chain was checking whether the file was legal. None of them was checking whether it was true.
How retailers score and charge for ASN failures
Vendor compliance programs, sometimes published as a routing guide or supplier requirements manual, score two things about an ASN separately: whether it arrived on time, and whether it was accurate. A shipment can fail one, both, or trigger several violation codes at once, and codes stack.
Flat fee per occurrence
The most common shape for timing violations. Commonly a few tens of dollars up into the low hundreds, per shipment, per violation code.
Per carton or per unit
Typical for label and scan failures, where the retailer's own cost scales with the number of cartons their team had to handle manually.
Percentage of PO or invoice value
Commonly a 1 to 5 percent band, often with a dollar floor per shipment and sometimes a cap per purchase order.
All three vary by retailer, by violation code, by whether you are a new vendor or an established one, and they are revised annually. The only authoritative figure for your account is in your own routing guide, and anyone quoting you a single industry-wide number is guessing.
The fee is rarely the real cost. The scorecard is. Programs typically set a compliance threshold in the mid-90s for ASN timeliness and accuracy, measured monthly or quarterly. Falling below it does not just add charges — depending on the account it can affect your receiving windows, your access to preferred appointment slots, and how you show up in a category review. Those consequences do not appear on any invoice, which is precisely why they get discovered late.
One mechanism worth understanding before you appeal anything. A wrong ASN does not just cost the retailer a correction; it forces a DC built around scan-based receiving to fall back to manual counting mid-shift, with the labour already scheduled and the doors already booked. That is why the fees are structured as deterrents rather than cost recovery, and why a first appeal without evidence rarely succeeds.
Deductions arrive as a code on a remittance advice weeks after the event. If you cannot reconstruct what you transmitted, when it was picked up, and what the warehouse confirmed shipped, you are not disputing anything. You are remembering.
Programs typically set the ASN timeliness and accuracy threshold in the mid-90s, measured monthly or quarterly. Below it the per-occurrence fee stops being the expensive part — receiving windows, appointment priority and category standing are what actually move, and none of them appear on an invoice.
How to actually fix it
Three controls, in order of how much money they recover.
1. Validate semantically before you transmit
Your translator checks whether the file is legal. It cannot check whether it is true. A pre-transmission gate confirms the things below. None of it is exotic. All of it is comparison against records you already hold.
2. Reconcile the 856 against what shipped, not what was planned
Generate the file from the shipping confirmation: the 945 from a third-party warehouse, or the shipment record in your own WMS. Then run a three-way check before transmission, the same way accounts payable matches an invoice: purchase order against shipping confirmation against the ASN you are about to send. If any of the three disagree on quantity, cartons, or line composition, the file does not go. This is the control that moves the quantity-variance number, and it is the one most teams do not have, because the two records live in systems that were never asked to talk.
3. Own the acknowledgement gap
Be clear up front that this control lives in your translator and your VAN, not above them, because that is the only layer where ISA13 sequences and 997 timers exist. Every outbound 856 gets an expected 997 window agreed per partner, and anything unacknowledged past that window pages a named person. Treat a missing 997 as more urgent than a rejection, because a rejection at least reported itself, and because a missing one cannot tell you whether the file or the acknowledgement went missing. Track the 824 application advice separately: a 997 accepted alongside an 824 rejection is a real and common state, and it means the partner's business application threw your shipment out after the syntax cleared. Reconcile ISA13 interchange control numbers per partner and per direction so a file that vanished between your gateway and theirs shows up as a numeric gap rather than as a deduction. How to scope and staff that layer is the subject of the EDI integration page; this page assumes it exists.
Alongside those, two habits. Move short-transit lanes to event-triggered transmission at dock departure rather than a batch cycle. And close the loop monthly by sorting your own ASN deductions by violation code.
Monday-morning version: pull last month's ASN-related deductions, tag each one as timing, hierarchy, quantity, or label, and count them. Three of those four are fixed at the moment the file is generated. The fourth is fixed at the printer. Knowing which bucket dominates tells you what to build before you talk to any vendor, including us.
Where Orkestra fits, and where it stops
Go back to the worked example. Nothing in that chain was broken. The translator did its job, the 997 came back clean, and the truck arrived on time. What was missing was a comparison: the document said 288 units and the warehouse record said 240, and no system in the path held both numbers at once.
What was missing was one thing no part of the EDI chain has: both numbers in the same place. Orkestra ingests ASN data alongside API feeds, flat files and portal data and normalizes it into one operational model, so the 856, the purchase order it references and the shipment record behind it stop being three files in three systems and become three views of one object. Once they sit in one model, a quantity that disagrees across them is a detectable condition instead of a discovery at the retailer's dock. The Integration Agent maps your data into Orkestra's canonical model and validates payloads on the way in — read that direction carefully, because it is the one people get wrong. It maps inbound, into our model. It does not author the partner-facing map that has to satisfy a retailer's 4010 implementation guide.
Now be exact about where in the clock that lands, because this is the part that gets oversold. Orkestra sees your 856 when a copy of it is fed to Orkestra, which for most teams is at or just after generation — not inside the translator. Wire your ASN generator to check Orkestra before it releases the file and the mismatch stops the file. Do not, and the mismatch surfaces after transmission, and what you get instead is time: on a lane with real transit, enough of it to send a BSN01 = 05 replacement that lands before the truck does. On a ninety-minute regional lane, not enough, and this page has already explained why. Both beat finding out on a remittance advice. They are not the same thing, and you should know which one you are buying.
From there it is ordinary exception handling. A variance you have defined as material becomes a case in exception management with a named owner and an SLA. The purchase order side of the same picture — the 850 and the open-order position the ASN is measured against — lives in order management. And when a deduction lands anyway, the dispute is won on evidence: what you transmitted, when it was collected, and what the warehouse confirmed shipped. Document management assembles that set as the shipment moves instead of someone rebuilding it from four systems in November. Avoiding the chargeback and winning the dispute are two different jobs.
What has to be true for any of it: the counterpart record has to reach Orkestra, and you have to decide what variance is worth stopping a file for. It is a comparison you configure once, not one that appears on its own. The same pattern shows up wherever a signal existed in time to act and nobody owned the response — it is the argument behind OTIF improvement too.
One published result worth putting beside this: OIA Global, a 4PL running a multi-client operation on Orkestra, cut exception resolution time by 60%. Whether that maps to your ASN deduction line depends entirely on how many of your deductions are detection failures rather than label failures — which is what the monthly sort in the previous section tells you before you speak to anybody, including us.
What Orkestra is not
Stated plainly so nobody discovers it on a technical call.
Orkestra does not transmit your 856. It is not a VAN and not an AS2 endpoint — your mailbox, your certificates and your trading partner keys stay exactly where they are.
It is not a translator. The partner-facing map that has to satisfy a retailer's 4010 implementation guide is authored and maintained somewhere else, and when they revise that guide, the remap is not ours.
It does not print your GS1-128 labels. So it cannot by itself guarantee the SSCC on the carton matches MAN02 in the file. What it can do is tell you the two records disagree, once both records are in it.
It does not watch ISA13 sequences or 997 timers, because those exist inside your translator and VAN and Orkestra is not in that path. If a file vanishes between your gateway and theirs, that gap is visible there, not here.
What Orkestra does sits one layer up: consume the ASN data, validate it against your model, and reconcile it against the order and the shipment record. If you need a VAN, an AS2 endpoint or a mapping service, those are separate purchases from separate vendors — how to scope them is on the EDI integration page.
