DEV Community: challan116-ux

The EDI 812, Decoded: A Credit/Debit Adjustment Is How a Deduction Stops Being an Argument

challan116-ux — Sun, 08 Nov 2026 14:28:18 +0000

The EDI 812, Decoded: A Credit/Debit Adjustment Is How a Deduction Stops Being an Argument

The EDI 812 · Credit/Debit Adjustment is how a trading partner tells you, in structured form, that the amount on an invoice is not the amount they intend to pay — and exactly why. It does not pay anything and it does not correct your invoice. It documents the claim: which invoice, which direction (credit or debit), which reason, and how much.

That sounds like bookkeeping trivia until you have lived through a deduction. A retailer short-pays an invoice by $412, the remittance advice shows a reason code, and finance is left arguing from screenshots and memory about whether the shortage was real, whether the price was wrong, or whether the shipment was late. The 812 exists to move that argument into data both systems can match, dispute, or accept — before it hardens into an unrecoverable write-off.

What is the EDI 812 · Credit/Debit Adjustment?

The 812 is an X12 transaction set used to communicate or request an adjustment to a previously billed amount. Either side can send it: a buyer claiming a credit for a pricing error or a shortage, or a seller requesting a debit for an under-billed shipment.

Three ideas define it:

It states a claim, not a verdict. Sending an 812 does not prove the adjustment is valid. It identifies the claim precisely enough that the other side can verify it against the original invoice, the shipment record, and the remittance.
It is anchored to the original document. A useful 812 references the invoice it adjusts. An adjustment floating free of its invoice is just a number looking for an argument.
It carries a reason, in code. Shortage, pricing discrepancy, damaged goods, late ASN, freight dispute — the reason code is what lets the receiver route the claim to the team that can actually resolve it, instead of a generic deductions inbox.

How is the 812 different from the 810, the 820, and the 997?

These four messages get confused constantly, and the confusion is expensive:

The 810 · Invoice states what you billed in the first place.
The 812 · Credit/Debit Adjustment states what one side says should change about that bill, and why.
The 820 · Payment Order / Remittance Advice states what was actually paid, including any deduction taken.
The 997 · Functional Acknowledgment only answers whether a file parsed. It says nothing about money.

A clean 997 on your 810 tells you nothing about whether you will be paid in full. The deduction story only becomes visible when you reconcile the 820 against the 810 — and the 812 is the document that explains the gap in structured form, when your partner sends one.

Where do 812 adjustments actually come from?

In practice, most adjustments trace back to a small set of causes:

Shortages and receiving discrepancies. The ASN said 100 cases, receiving counted 96. The buyer credits itself for the missing four. The fix upstream is rarely in accounting — it is in the accuracy of the 856 · Advance Ship Notice against what was physically packed.

Pricing mismatches. The invoice price does not match the price on the purchase order or in the item file. This is the most preventable category: it is a master-data problem surfacing as a finance problem, usually weeks after the order shipped.

Compliance chargebacks. Late or inaccurate ASNs, label errors, missed ship windows. Retailers deduct these under their compliance programs, and the adjustment documents the penalty. Whether you can dispute it depends entirely on whether your own records — timestamps, label scans, carrier data — are as structured as theirs.

Freight and allowance disputes. Freight billed differently than agreed, or a promotional allowance claimed twice. These need the original agreement terms matched line by line, not a phone call.

What breaks when teams handle adjustments badly?

The adjustment is posted without matching. Someone in finance posts the credit to clear the receivable, and the underlying shortage or pricing error never gets fixed — so it recurs on the next order, and the next. Posting is not resolving.

Nobody owns the reason codes. If deductions land in one undifferentiated bucket, you cannot see that 60% of your write-offs are one retailer's ASN timing rule. Aggregation hides the fixable pattern.

The dispute window closes. Most retailer programs give you a limited window to dispute a deduction with evidence. Teams that discover adjustments at month-end close have often already lost the right to argue, however good their evidence is.

The corrected-invoice question gets skipped. An 812 does not replace a corrected invoice where your partner's process requires one. Assuming the adjustment document settles the billing record — when the partner expected a re-billed 810 — leaves the accounts out of sync in the opposite direction.

How should you reconcile an 812 before posting it?

Match it to the original invoice. Every line of the claim should trace to a billed line. Anything that does not trace is a question, not a posting.
Compare it with the remittance. Does the deduction on the 820 equal the adjustment claimed on the 812? A mismatch between the two is itself a finding.
Verify the claim against your own evidence. Shipment records for shortages, the order and price file for pricing, transmission logs for ASN timing.
Decide explicitly: accept, dispute, or partially accept. Record the decision and the reason where the next adjustment from the same partner will find it.

That fourth step is the one that compounds. A log of accepted-versus-disputed adjustments, by partner and reason code, is how a deductions problem turns into a short list of operational fixes.

Frequently asked questions

Does an 812 move money?
No. It communicates or requests an adjustment. Money moves through payment — the 820 · Payment Order / Remittance Advice is where the actual deduction shows up.

Can a seller send an 812, or only buyers?
Both. A buyer commonly sends one to claim a credit; a seller can send one to request a debit, for example for an under-billed amount. Direction depends on who is asserting the change.

Is an 812 the same as a credit memo?
It is the EDI expression of the same business idea, but it is not automatically your accounting system's credit memo. Most teams map an accepted 812 into their ERP's credit or debit memo process rather than posting the EDI document directly.

What is the difference between an 812 and an 824?
The 824 · Application Advice reports errors found when a document was applied to a business system. The 812 asserts a financial adjustment to a billed amount. One is about document validity; the other is about money owed.

Adjustments are where EDI stops being a data-format conversation and becomes a margin conversation. The partners who handle them well are not the ones with the fewest deductions — they are the ones whose deductions arrive structured, get matched before they get posted, and feed back into the ASN, pricing, and packing processes that caused them.

I build SignalEDI to help SMB teams handle exactly this layer — validation before transmission, acknowledgments and adjustments reconciled against the original documents, so a deduction is a work item with evidence attached, not a surprise at month-end.

— Chris, founder of SignalEDI

The EDI 824, Decoded: An Application Advice Is Your Partner Telling You Exactly What Was Wrong

challan116-ux — Sat, 07 Nov 2026 14:28:17 +0000

The EDI 824 · Application Advice is how a trading partner reports, in structured form, the errors it found when it applied your document to its business system. A 997 · Functional Acknowledgment says your file arrived and parsed. An 824 says whether the content inside it was acceptable — and if not, which element, which value, and why.

That distinction is the whole point. Most integration failures that cost real money are not syntax failures. The file was well-formed, the envelope was correct, and the acknowledgment came back clean — and then the order, claim, or invoice was quietly rejected downstream because a price, a code, or a reference did not match what the receiver's system expected. The 824 exists to make that rejection explicit, machine-readable, and fixable, instead of leaving it to surface weeks later as a missing payment or a chargeback.

What is the EDI 824 · Application Advice?

The 824 is an X12 transaction set a receiver sends back after application-level validation of a document you sent. It can report acceptance, rejection, or acceptance with errors noted, and it can do so for a whole transaction or for individual elements inside it.

Three ideas define it:

It reports business validation, not transport or syntax. Prices that do not match the catalog, item codes the receiver does not recognize, quantities outside tolerance, references that do not resolve — these are application errors, and they are what the 824 carries.
It points at the problem. A useful 824 identifies the offending segment and element and carries a coded description of the error, so the fix is a specific edit, not an investigation.
It closes the loop the 997 leaves open. The 997 · Functional Acknowledgment answers "did it parse?" The 824 answers "did it pass?" A flow that only watches the first question will call rejected documents successful.

The healthcare world has its own specialized cousin — the 277CA for claim acknowledgments — but the 824 is the general-purpose version used across retail, distribution, and manufacturing flows, often returned for 850 · Purchase Order, 810 · Invoice, and other inbound documents a partner validates before posting.

How is the 824 different from the 997?

The 997 · Functional Acknowledgment works at the envelope and syntax layer. It confirms receipt of a functional group and reports structural errors: bad segments, wrong element types, broken control counts. It says nothing about whether the business content was right.

The 824 · Application Advice works one layer up. The document parsed fine; the question is whether the receiver's application accepted it. An 810 · Invoice can be syntactically perfect and still earn an 824 rejecting it because the billed price disagrees with the purchase order it references.

Treating a clean 997 as success is one of the most common EDI design mistakes. The acknowledgment ladder is: transport receipt, then syntax acknowledgment, then application advice. Each rung answers a different question, and stopping at rung two leaves the most expensive failures invisible.

Why do application rejections go unnoticed?

Because they arrive as a document type nobody wired into the workflow. The sender's system posts the outbound file, records the 997, marks the exchange complete, and moves on. The inbound 824 lands in a mailbox or a folder, unparsed, while the business assumes the invoice is in the payment queue or the order is in production.

Weeks later the truth arrives in the worst possible form: a payment that never comes, a shipment that never started, a partner asking why you never fixed the errors they sent you. They did tell you — in the 824, on the day it happened. The failure was not communication; it was that nobody built the step that listens.

Where do 824 flows usually break?

The first break is the unmonitored inbox. Inbound application advices are received but never translated into work — no alert, no ticket, no owner. The fix is to treat an 824 reporting rejection like an operational alarm, because that is what it is.

The second break is advice without context. An 824 references the original document by its control or reference numbers; if your system cannot join the advice back to the exact outbound transaction and version, the error report is unactionable. Joining must be by construction, not by someone searching folders.

The third break is partial rejection read as total success — or total failure. An 824 can accept most of a transaction and reject individual lines or elements. Systems that collapse that into a single pass/fail either resend good data (creating duplicates) or discard good lines with the bad. Read the advice at the level it was written.

The fourth break is fixing the instance, not the cause. A rejected price gets manually corrected and resent, while the catalog mismatch that caused it produces the same rejection on the next invoice. Every recurring 824 error code is a defect in a map, a master-data record, or a partner agreement — fix it there and the stream of advices dries up.

The fifth break is never sending advices yourself. If you receive documents, your partners deserve the same clarity: validate at application level and return specific, element-level errors promptly, while the sender can still correct and resend inside the business window.

What should you check in an 824 flow?

Five checks keep application advice working:

First, coverage: for every outbound document type that matters, do you know whether your partner returns an 824, a proprietary report, or silence — and is silence being mistaken for acceptance?

Second, routing: does every inbound 824 get parsed, joined to its original transaction, and turned into an owned task the same day it arrives?

Third, granularity: can your handling act on line- and element-level results, accepting what passed and correcting only what failed?

Fourth, recurrence: are you counting 824 errors by code and partner, so the top causes get fixed at the map or master-data level instead of one document at a time?

Fifth, symmetry: do you return equally specific application advice for the documents you receive, promptly enough for your partners to act on it?

A flow that runs those checks turns rejections from surprises into same-day corrections: the partner told you exactly what was wrong, in a format your system can act on — all you had to do was listen at the right layer.

Frequently asked questions

Who sends the EDI 824 · Application Advice?
The receiver of a document sends it to the original sender after application-level validation. It reports whether the document was accepted, rejected, or accepted with errors, and identifies the specific segments and elements involved.

What is the difference between the EDI 824 and the EDI 997 · Functional Acknowledgment?
The 997 reports receipt and syntax: whether the file arrived and parsed correctly. The 824 reports business acceptance: whether the content passed the receiver's application checks. A document can earn a clean 997 and still be rejected by an 824.

Which documents does an 824 usually report on?
Any document a partner validates before posting — commonly the 850 · Purchase Order and the 810 · Invoice in retail and distribution, and a range of documents in manufacturing and healthcare-adjacent flows that use the general-purpose advice instead of a specialized acknowledgment.

What should happen when an 824 reports a rejection?
The advice should be joined automatically to the original transaction, routed to an owner the same day, and corrected at the level reported — resending only the failed lines where the advice is partial, and fixing recurring causes in the map or master data.

Can an 824 accept part of a document and reject part of it?
Yes. That partial reporting is one of its strengths: it can accept a transaction while flagging specific elements or lines. Handling that ignores the granularity either duplicates good data or discards it.

I build SignalEDI, an EDI and API integration platform for SMBs — application-level error reporting is exactly the layer we think most integrations under-build. If your team only watches functional acknowledgments, it is worth asking what your partners have been trying to tell you: signaledi.com

— Chris, founder of SignalEDI

The EDI 210, Decoded: A Freight Invoice Is Only Payable When Three Other Messages Agree With It

challan116-ux — Fri, 06 Nov 2026 14:26:35 +0000

The EDI 210 · Motor Carrier Freight Details and Invoice is how a motor carrier asks to be paid for a load it moved. It is the last message in the freight chain — the 204 · Motor Carrier Load Tender asks, the 990 · Response to a Load Tender decides, the 214 · Transportation Carrier Shipment Status Message narrates, and the 210 bills.

That position is what makes the 210 different from an ordinary invoice. A carrier's invoice is not payable because it arrived, and it is not payable because its arithmetic is clean. It is payable when three earlier records agree with it: the rate the shipper offered and the carrier accepted, the stops and service the tender described, and the times and events the status messages reported. When those three disagree with the bill, the honest answer is not "pay it and sort it out later" — it is a dispute that reopens work the delivery was supposed to close.

What is the EDI 210 · Motor Carrier Freight Details and Invoice?

The 210 is an X12 transaction set a motor carrier sends to the party that tendered the load — a shipper, broker, or 3PL — after delivery. It carries the charge for the movement: the base linehaul, fuel surcharge, and any accessorial charges such as detention, layover, lumper, or stop-off fees, each tied to the shipment it belongs to.

Three ideas define it:

It bills against a commitment, not a trip. The reference point is the accepted 204: the rate, equipment, origin, destination, and service level both sides agreed to when the carrier answered with a 990. Charges that were never part of that agreement need evidence, not just a line item.
Accessorials stand or fall on the 214 record. Detention claims depend on arrival and departure times. A layover claim depends on what happened and when. The status messages the carrier sent during the trip are now the evidence for — or against — the charges on the invoice.
One 210, one shipment's truth. A freight invoice that bundles, splits, or re-references shipments differently from how they were tendered forces the payer to reconstruct the load before they can audit it. Most "slow pay" in freight is reconstruction work, not reluctance.

A 210 is usually generated from the carrier's billing system after the proof of delivery is in hand, which is why its quality depends on how cleanly the dispatch, status, and document records were joined before billing ever started.

How is the 210 different from the 204, the 990, and the 214?

The 204 · Motor Carrier Load Tender is the offer: this load, at this rate, with these stops and requirements. It sets the price the movement was supposed to cost.

The 990 · Response to a Load Tender is the carrier's answer — accept or decline — and the moment that offered rate becomes a committed rate.

The 214 · Transportation Carrier Shipment Status Message is the narration during the trip: pickup, departure, arrival, delay, and delivery events, with the times that later justify or undermine accessorial charges.

The 210 · Motor Carrier Freight Details and Invoice is the bill that must be reconciled against all three. Tender says what was agreed, the acceptance says who committed to it, the status record says what actually happened — and the invoice is only as trustworthy as its agreement with that history.

Why do freight invoices get disputed so often?

Not because carriers bill carelessly and not because shippers pay slowly by nature. Freight invoices get disputed because the audit is a three-way match performed on records that were created by different systems, at different times, under different references — and any mismatch parks the invoice in a queue where a person has to rebuild the story of one load by hand.

That reframes what a good 210 flow is. The goal is not a prettier invoice. The goal is an invoice that arrives already attached to its evidence: the accepted tender it bills against, the status events that support its accessorials, and the delivery confirmation that proves the work finished. An invoice that audits itself gets paid. An invoice that needs archaeology waits.

Where do 210 flows usually break?

The first break is the rate mismatch. The invoice bills a different linehaul or fuel surcharge than the accepted tender carried — because the rate changed verbally, the tender was amended without a clean version, or billing worked from a quote instead of the commitment. The fix is boring and total: bill from the accepted tender record, and make a rate change produce a new agreed record, not a phone call.

The second break is the unsupported accessorial. Detention is billed, but the 214 record shows arrival and departure times that make the detention window impossible — or shows no arrival event at all. The charge may be legitimate; without the status evidence it is unpayable, and the dispute costs more than the fee. Carriers who report times carefully are, in effect, pre-filing the evidence for their own invoices.

The third break is the orphan invoice. The 210 references a shipment the payer cannot match — a tender under a different number, a load that was re-brokered, a reference typed one character differently. Like an orphan status message, an unmatched invoice is real work that cannot be processed, and it ages in a queue while both sides believe the other is at fault.

The fourth break is billing before the story is complete. The invoice arrives before the final delivery status or the proof of delivery, so the payer holds it — correctly — and the carrier reads the hold as slow payment. Sequence matters on the money side too: tender, acceptance, status, proof, then invoice, each step making the next one checkable.

The fifth break is duplicate billing of the same movement: a corrected invoice sent without clearly voiding the first, or the same load billed by both a broker and the underlying carrier. Deduplication here is the same discipline as anywhere else in integration — a correction must replace a specific earlier document, identifiably, or a payer protecting themselves will pay neither until a human sorts it out.

What should you check in a 210 flow?

Five checks keep freight billing honest:

First, three-way match by construction: does every 210 resolve automatically to its accepted 204 and its 214 history — and how large is the queue of invoices that cannot, and who owns it?

Second, accessorial evidence: for each accessorial charge, can the system point to the specific status events that justify it, with times that make the charge arithmetically possible?

Third, rate provenance: is the billed rate provably the rate from the accepted tender, with any change represented as its own agreed record rather than an edit nobody can see?

Fourth, completeness before billing: is the final delivery event and proof of delivery on file before the invoice is generated — or are holds doing that check expensively, one invoice at a time?

Fifth, correction discipline: does a corrected 210 identify exactly which invoice it replaces, so the payer never faces two live bills for one load?

A flow that runs those checks turns the 210 from an argument into a formality: the last message in the chain simply states what the earlier three already proved.

Frequently asked questions

Who sends the EDI 210 · Motor Carrier Freight Details and Invoice?
The motor carrier that moved the load sends it to the shipper, broker, or 3PL that tendered the load. It is the carrier's invoice for the linehaul, fuel surcharge, and any accessorial charges for that shipment.

What is the difference between the EDI 210 and the EDI 810 · Invoice?
The 810 is the general-purpose invoice used for goods — it bills against a purchase order for products. The 210 is specific to motor carrier freight: it bills for a transportation service against an accepted load tender, and its accessorial charges are audited against shipment status events.

Why would a valid 210 be held instead of paid?
Usually because its evidence is missing or mismatched: the billed rate differs from the accepted tender, an accessorial lacks supporting arrival or departure times, the delivery proof has not arrived, or the invoice cannot be matched to a shipment. The hold is the audit working, not failing.

How do 214 status messages affect a 210 invoice?
Directly. Detention, layover, and similar accessorials are calculated from the arrival, departure, and delay events reported in 214 messages. Gaps or contradictions in that record are the most common reason an otherwise correct accessorial charge gets disputed.

Can a carrier send more than one 210 for the same load?
A corrected invoice can replace an earlier one, but it must identify the document it replaces. Two live, unlinked invoices for the same movement look like duplicate billing to any payer's controls, and both will typically be held until the duplication is resolved.

A freight invoice is not the end of paperwork — it is the moment every earlier message gets graded. The 210 gets paid quickly when the tender it bills against is unambiguous, the status record supports its charges, and the delivery it closes is already proven. At SignalEDI, we treat the freight chain — 204 · Motor Carrier Load Tender, 990 · Response to a Load Tender, 214 · Transportation Carrier Shipment Status Message, 210 · Motor Carrier Freight Details and Invoice — as one reconciled story, because carriers get paid on the strength of the whole chain, not the last document alone. I'm Chris, founder of SignalEDI, and we build EDI that keeps those records in agreement for shippers, brokers, and the carriers hauling for them.

The EDI 214, Decoded: A Shipment Status Message Is Only Useful If It Arrives While You Can Still Act

challan116-ux — Thu, 05 Nov 2026 14:32:04 +0000

The EDI 214 · Transportation Carrier Shipment Status Message is how a carrier reports what is happening to a load after it has been accepted: picked up, departed, arrived, delayed, delivered. It is the narration in the freight chain — the 204 · Motor Carrier Load Tender asks, the 990 · Response to a Load Tender decides, the 214 narrates, and the 210 · Motor Carrier Freight Details and Invoice bills.

A 214 that arrives late is not a status. It is history. The value of every event in a 214 is set by whether the receiver can still do something with it — reroute, warn the dock, tell the customer, reschedule the appointment — and that window closes fast. Teams that treat status messages as a log to file, rather than a feed to act on, end up with perfect records of failures nobody prevented.

What is the EDI 214 · Transportation Carrier Shipment Status Message?

The 214 is an X12 transaction set a motor carrier sends while a shipment it accepted is in progress, and at its end. Each message carries a status event: the pickup happened, the truck departed a stop, it arrived at a stop, it is delayed, or the delivery is complete. Events normally reference the shipment from the accepted 204, identify which stop they describe, and carry the date and time the event actually occurred — which is not always the date and time the message was sent.

Three ideas define it:

It only exists against an accepted tender. A 214 narrates a commitment. If the load was never accepted with a 990, status events have nothing true to attach to.
An event has two times, and both matter. The occurrence time says when the pickup, arrival, or delay happened in the real world. The transmission time says when you learned it. A delivery that happened at 09:00 and was reported at 16:00 was invisible for seven hours, and planning made in those hours was made blind.
Sequence is meaning. Picked up, departed, arrived, delivered is a story in order. The same events arriving out of order — delivered reported before arrived, a delay reported after the delivery — are not just untidy; applied naively, they move a shipment's state backwards.

A 214 is usually generated from the carrier's dispatch and driver systems, increasingly from telematics, which is why its events can be frequent, automated, and — when nobody has defined which events matter — overwhelming.

How is the 214 different from the 204, the 990, and the 210?

These four documents form one freight chain, and the 214 is its running commentary:

The 204 · Motor Carrier Load Tender opens the chain: the shipper or broker offers the load, with stops, windows, equipment, and commodity detail.
The 990 · Response to a Load Tender is the carrier's answer — accept or decline — and the moment capacity is actually committed.
The 214 · Transportation Carrier Shipment Status Message flows during the trip: pickup, departure, arrival, delay, and delivery events against the accepted tender.
The 210 · Motor Carrier Freight Details and Invoice closes the money side after delivery, and it is audited against what the accepted tender promised and what the 214 says actually happened.

A useful shorthand: the 204 asks, the 990 decides, the 214 narrates, and the 210 bills. If the narration is late, out of order, or attached to the wrong load, the bill inherits the confusion.

Why does timing matter more than completeness in a 214?

Because freight decisions expire. Knowing a truck will miss a 14:00 appointment is valuable at 11:00 and almost worthless at 13:55. A status feed that eventually contains every event, in perfect detail, but delivers delay events after the window to act has closed will still produce missed appointments, idle dock crews, and surprised customers.

That changes what "good" means for a 214 flow. Completeness is a record-keeping virtue. Timeliness is the operational one. The flows worth trusting are measured on the gap between when something happened and when the receiver's system reflected it — not on how many event types they support.

Where do 214 flows usually break?

The first break is the late delay. The carrier knew the truck was behind — the driver reported it, dispatch saw it — but the delay event reaches the shipper after the appointment is already missed. Nothing in the document was wrong; it simply arrived when it could no longer change anything. The fix is to monitor the occurrence-to-receipt gap on exception events specifically, not average message latency.

The second break is out-of-order application. A delivered event is applied, then a late arrived event arrives and the system moves the shipment back to "arrived." State should only move forward: an event older than the state it would replace is information for the record, not an instruction to rewind the present.

The third break is the orphan status. The 214 references a shipment identifier the receiver cannot match — a tender that changed versions, a reference typed differently, an accepted load recorded under another number. The event is real and now useless, because narration attached to the wrong load, or to no load, misleads everyone who reads it.

The fourth break is silence mistaken for "on track." No event has arrived, so the dashboard shows the load progressing as planned. In freight, absence of a status is itself a status — a checkpoint that should have reported by now and has not is an exception worth raising before the appointment does it for you.

The fifth break is noise drowning signal. Automated location pings and routine checkpoints flood the feed until the one delay event that matters is the 400th row nobody reads. Exception events need a different path from routine ones: surfaced, timed, and owned.

What should you check in a 214 flow?

Five checks keep a status feed honest:

First, latency on exceptions: how long between a delay occurring and your system showing it — and is that gap measured and alarmed, or discovered by the customer?

Second, forward-only state: can a late, older event move a shipment's current state backwards, or is it filed to history without rewinding the present?

Third, matching: does every incoming 214 resolve to the accepted tender and the right stop — and what happens to the ones that do not match? An unmatched-event queue that nobody owns is a silent blind spot.

Fourth, expected-event monitoring: for each load, do you know which event should arrive next and by when — so that silence raises an exception instead of reading as calm?

Fifth, signal separation: do delay and exception events reach a person or a workflow immediately, separately from routine checkpoint traffic?

A flow that runs those checks turns the 214 from a diary into an instrument: you learn what is wrong while there is still time to do something about it.

Frequently asked questions

Who sends the EDI 214 · Transportation Carrier Shipment Status Message?
The motor carrier (or its dispatch/telematics provider) sends it to the shipper, broker, or 3PL that tendered the load. It reports events on a shipment the carrier previously accepted.

What is the difference between the EDI 214 and the EDI 990 · Response to a Load Tender?
The 990 is a one-time decision before the trip — accept or decline the tender. The 214 is the stream of events during and after the trip: pickup, arrival, delay, and delivery. The 990 commits; the 214 narrates the commitment being kept.

Why do 214 status events arrive out of order?
Because events are generated in different places — driver apps, dispatch systems, telematics — and transmitted in batches or after connectivity gaps. The event's occurrence time, not its arrival time, sets its place in the story, and receiving systems should apply events forward-only.

What happens after the final 214 delivery event?
The carrier invoices with a 210 · Motor Carrier Freight Details and Invoice. The receiver audits that invoice against the accepted 204 · Motor Carrier Load Tender and the 214 record — accessorials for detention, for example, stand or fall on the arrival and departure times the 214 reported.

Is a missing 214 event a problem?
Yes, if the event was expected. A pickup confirmation that has not arrived by its window is an exception in its own right. Treating silence as "on track" is how a missed pickup is discovered at the delivery appointment instead of at the pickup.

A status that arrives after the decision it was meant to inform is not visibility — it is an archive. The 214 works when its events arrive in time, in order, attached to the right load, with silence itself treated as a signal. At SignalEDI, we treat the 214 as the live half of the freight chain — tender, answer, status, invoice — because freight disputes and freight saves are both decided by whose status was true while it still mattered. I'm Chris, founder of SignalEDI, and we build EDI that keeps those states honest for shippers, brokers, and the carriers hauling for them.

The EDI 990, Decoded: A Response to a Load Tender Is Where Capacity Actually Gets Committed

challan116-ux — Wed, 04 Nov 2026 14:27:59 +0000

The EDI 990, Decoded: A Response to a Load Tender Is Where Capacity Actually Gets Committed

The EDI 990 · Response to a Load Tender is the carrier's answer to a 204 · Motor Carrier Load Tender — accept the load, or decline it. It is one of the shortest documents in freight EDI, and it carries the most consequential single bit in the chain: until a 990 acceptance arrives, no truck is committed, no matter how confidently the shipper's system shows the load as covered.

That brevity is the trap. Because the 990 says so little, teams treat it as a formality — a receipt to file — instead of what it is: the moment a tender stops being an offer and becomes a commitment both sides will later audit the 214 · Transportation Carrier Shipment Status Message and the 210 · Motor Carrier Freight Details and Invoice against.

What is the EDI 990 · Response to a Load Tender?

The 990 is an X12 transaction set a motor carrier sends in reply to a 204. It references the tender it answers and states, in essence, one decision: accepted or declined. An acceptance commits the carrier to run the load as tendered — the stops, windows, equipment, and commodity detail in the 204. A decline releases the shipper to tender the load to the next carrier, ideally while there is still time to do so.

Three ideas define it:

It is the commitment point, not the tender. The 204 · Motor Carrier Load Tender asks. The 990 answers. A load is covered when an acceptance is received and applied — never when the tender is sent.
A decline is valuable information, delivered on a clock. A fast decline is a gift: it frees the load for re-tender inside its response window. A slow decline, or silence mistaken for acceptance, is how freight misses its pickup.
It answers a specific tender version. If the 204 changed after it was sent — a moved appointment, an added stop — the 990 accepts the version it references. Accepting version one while the shipper plans version two is a dispute built at the moment of agreement.

A 990 is usually generated by the carrier's transportation system the moment a dispatcher or an automated scoring rule decides on the tender, which is why its timing — not just its content — is operationally meaningful.

How is the 990 different from the 204, the 214, and the 210?

These four documents form one freight chain, and the 990 is its hinge:

The 204 · Motor Carrier Load Tender opens the chain: the shipper or broker offers the load, with stops, windows, equipment, and commodity detail.
The 990 · Response to a Load Tender is the answer — accept or decline. It is short, and it is the moment capacity is actually committed or released.
The 214 · Transportation Carrier Shipment Status Message flows during the trip, but only against an accepted tender: pickup, departure, arrival, and delivery events.
The 210 · Motor Carrier Freight Details and Invoice closes the money side after delivery, audited against what the accepted 204 promised.

A useful shorthand: the 204 asks, the 990 decides, the 214 narrates, and the 210 bills. Skip the decision, and the narration and the bill are both built on an assumption.

Why does such a short document deserve its own controls?

Because every failure around it is a state failure, not a data failure. The 990 carries almost no detail to get wrong — so when a tender flow breaks here, it breaks because a system recorded the wrong state: a sent tender marked covered, a decline loaded as an acceptance, a timeout nobody noticed, an acceptance applied to the wrong shipment.

Those are bookkeeping errors with physical consequences. A truck is dispatched, or not. A dock crew is scheduled, or not. Spot rates are paid, or not. The document is small; the state it creates runs the day.

Where do 990 flows usually break?

The first break is the unapplied response. The 990 arrives — by EDI, it lands in a mailbox or a queue — but nothing in the shipper's system changes the load's state. The tender still shows as pending while the carrier, having accepted, plans the pickup, or having declined, plans nothing at all. The fix is unglamorous: a response is not received until the load's state reflects it.

The second break is silence treated as soft acceptance. Tender relationships run on response windows. When a window closes with no 990, the correct state is timed out — re-tender now — not "probably fine." Monitoring tender ageing, and treating expiry as an event that changes state automatically, is what separates a recovered load from a missed one.

The third break is the decline that never triggers the next step. A decline should start the routing guide's next move immediately: the next carrier, the spot board, a call. A decline that sits in a queue for a human to notice has spent the one resource tendering cannot recover — time inside the pickup window.

The fourth break is version drift. The tender was updated after the original 204 — a new window agreed by phone — and the carrier's 990 accepts the original. Both sides believe they agree. They agree about different loads. Every post-tender change needs an updated 204, so the acceptance has one unambiguous thing to point at.

What should you check in a 990 flow?

Four checks keep a tender answer honest:

First, state discipline: is every load's state driven by the 990 actually received — accepted, declined, or timed out — rather than by the tender having been sent?

Second, application, not arrival: does an incoming 990 change the load's state automatically, or can a response sit received-but-unapplied while people plan around a stale status?

Third, decline handling: does a decline immediately trigger the next routing step, with the clock visible, instead of waiting for someone to notice it?

Fourth, version integrity: does the acceptance reference the current tender version, and does every change produce an updated 204 for a fresh, unambiguous answer?

A flow that runs those checks makes the shortest document in freight do its full job: turning an offer into a commitment both sides can prove.

Frequently asked questions

Is a load booked when the 204 · Motor Carrier Load Tender is sent?
No. The 204 is the offer. The carrier's 990 · Response to a Load Tender accepting it is what commits capacity — a tender that was sent but never accepted covers nothing.

What is the difference between the EDI 990 and the EDI 997 · Functional Acknowledgment?
The 997 · Functional Acknowledgment says a document was received and passed syntax checks. The 990 is a business decision — accept or decline the load. A 997 for your 204 tells you the tender arrived; only a 990 tells you whether you have a truck.

How fast must a carrier answer with a 990?
It depends on the relationship's routing guide — response windows of minutes to a few hours are common, and an unanswered tender is usually re-tendered to the next carrier when the window closes. That is why a fast decline is more useful than a slow maybe.

What happens after a carrier accepts with a 990?
The carrier executes the pickup and delivery and reports progress with 214 · Transportation Carrier Shipment Status Messages, then invoices with a 210 · Motor Carrier Freight Details and Invoice after delivery. Each later document is checked against the accepted tender.

Can a carrier decline a 990 after accepting?
Not cleanly — an acceptance is the commitment the rest of the chain is built on. A carrier that cannot run an accepted load has to communicate that change explicitly and immediately; silently not showing up turns a state problem into a service failure and, usually, a spot-rate bill for someone.

An offer is not a plan, and a receipt is not an answer. The 990 works when both sides treat its one decision — and its timing — as the state everything else is built on. At SignalEDI, we treat the 990 as the hinge of the freight chain — tender, answer, status, invoice — because freight disputes are won by the side whose states were true. I'm Chris, founder of SignalEDI, and we build EDI that keeps those states honest for shippers, brokers, and the carriers who answer them.

The EDI 204, Decoded: A Motor Carrier Load Tender Is an Offer a Carrier Can Refuse

challan116-ux — Tue, 03 Nov 2026 14:26:41 +0000

The EDI 204 · Motor Carrier Load Tender is the document a shipper or broker sends when freight needs a truck and a carrier has to decide — accept the load or refuse it, usually fast. Where the 850 · Purchase Order asks a supplier to sell goods, the 204 asks a carrier to commit capacity: a specific shipment, at specific pickup and delivery points, inside specific time windows. The carrier's answer comes back in the 990 · Response to a Load Tender, and once accepted, the tender becomes the contract the rest of the freight documents are measured against.

That decision window is what makes the 204 unforgiving. A tender that sits unread, or is read with a wrong weight, a wrong appointment time, or a wrong stop sequence, does not just create paperwork noise — it puts the wrong truck in the wrong place, or no truck at all, on the day the freight has to move.

What is the EDI 204 · Motor Carrier Load Tender?

The 204 is an X12 transaction set a shipper, broker, or 3PL uses to tender a shipment to a motor carrier. It carries the shipment identification, the parties, every stop in order — pickup, any intermediate stops, and final delivery — the dates and time windows for each stop, the equipment required, and the commodity detail: pieces, weight, dimensions, and handling notes.

Three ideas define it:

It is an offer, not an assignment. Until the carrier accepts with a 990 · Response to a Load Tender, no truck is committed. Treating a sent tender as a booked load is the first and most expensive misunderstanding in freight EDI.
The stop sequence is the shipment. A multi-stop load is not a pickup plus a delivery with extras; the order of stops, and the window attached to each one, is what the carrier actually plans a route and a driver around.
The detail is operational, not decorative. Weight, cube, equipment type, and appointment windows decide whether the carrier can legally and physically run the load. A tender with placeholder weights tenders a fiction.

A 204 is usually generated from a transportation management system (TMS) at the moment a load is planned, and it supersedes phone calls and rate-confirmation emails as the machine-readable statement of what is being asked.

How is the 204 different from the 210, the 214, and the 990?

These four documents form one freight chain, and confusing any two of them breaks it:

The 204 · Motor Carrier Load Tender opens the chain: the shipper or broker offers the load, with stops, windows, equipment, and commodity detail.
The 990 · Response to a Load Tender is the carrier's answer — accept or decline. It is short, and it is the moment capacity is actually committed or released.
The 214 · Transportation Carrier Shipment Status Message flows during the trip: the carrier reports pickup, departure, arrival, and delivery events against the accepted tender.
The 210 · Motor Carrier Freight Details and Invoice closes the money side: after delivery, the carrier bills the shipment, and the invoice is audited against what the accepted 204 promised and what the 214 reported.

A useful shorthand: the 204 asks "will you take this load, on these terms?", the 990 answers, the 214 narrates, and the 210 bills. A freight audit that compares the 210 only to the rate, without the accepted 204 behind it, is checking an invoice against half a contract.

Why do shippers tender loads electronically instead of calling carriers?

Because tendering is a decision with a deadline, at volume. A shipper tendering dozens or hundreds of loads a day cannot work a phone tree for each one, and a carrier cannot staff one either. The 204 makes the offer machine-readable so a carrier's system can score it — lane, equipment, driver hours, network balance — and answer with a 990 in minutes.

The deeper reason is the audit trail. A phone tender leaves two memories of the terms; a 204 leaves one document. When the invoice arrives as a 210 and the accessorials do not match what anyone remembers agreeing to, the accepted tender is what settles the argument — which is why the version the carrier accepted, not the version the shipper first sent, is the one worth keeping.

Where do 204 flows usually break?

The first break is the tender treated as a booking. The shipper's team sees the 204 go out and plans as if the load is covered, while the carrier has not yet answered — or has already declined with a 990 nobody loaded. The fix is a state rule, enforced in the system: a load is covered when the acceptance is received and applied, never when the tender is sent.

The second break is the silent timeout. Many tender relationships run on response windows — accept within an hour or the load moves to the next carrier in the routing guide. If a 990 decline or a non-response is not monitored, the load sits in a dead tender while its pickup window closes. Monitoring tender ageing, not just tender transmission, is the control that catches this.

The third break is bad operational detail. Wrong weight, wrong equipment, a delivery window copied from the last load: the carrier accepts in good faith and discovers the truth at the dock, where it becomes a refused pickup, a re-tender at spot rates, or a service failure charged to the wrong party. The 204 is only as honest as the planning data behind it, and it is the worst place in the chain to discover that data was estimated.

The fourth break is the unrecorded change. Pickup times move and stops get added after acceptance, often by phone. If the change never becomes an updated 204, the carrier runs the original plan, the 214 statuses look wrong against the shipper's expectations, and the 210 audit inherits a dispute nobody can reconstruct.

What should you check in a 204 flow?

Four checks keep a load tender honest:

First, acceptance discipline: is every load's state driven by the 990 response actually received — accepted, declined, or timed out — rather than by the tender having been sent?

Second, tender-ageing alarms: is any tender approaching its response deadline without an answer flagged while there is still time to re-tender?

Third, detail fidelity: do weight, equipment, stops, and windows in the 204 match the physical load and the appointments, checked before the tender goes out rather than at the dock?

Fourth, change capture: does every post-acceptance change produce an updated tender in the system of record, so the 214 events and the 210 invoice can be audited against the terms the carrier actually agreed to?

A flow that runs those checks turns the 204 from an electronic phone call into what it is meant to be: a decision both sides can prove.

Frequently asked questions

Is an EDI 204 · Motor Carrier Load Tender a booking?
Not by itself. The 204 is the offer. The carrier's 990 · Response to a Load Tender accepting it is what commits capacity — a tender that was sent but never accepted covers nothing.

What is the difference between the EDI 204 and the EDI 210?
The 204 · Motor Carrier Load Tender offers the load before it moves, with stops, windows, and equipment. The 210 · Motor Carrier Freight Details and Invoice bills the shipment after delivery, and is audited against the accepted tender.

How fast must a carrier answer a 204?
It depends on the relationship's routing guide — response windows of minutes to a few hours are common, and an unanswered tender is usually re-tendered to the next carrier when the window closes. That is why monitoring ageing tenders matters as much as sending them.

What happens after a carrier accepts a 204?
The carrier executes the pickup and delivery and reports progress with 214 · Transportation Carrier Shipment Status Messages, then invoices with a 210 after delivery. Each later document is checked against the accepted tender.

Does a small shipper need the 204?
Only if it tenders freight to carriers at any real volume, or its broker or 3PL tenders on its behalf. A shipper booking an occasional load by phone or portal does not need EDI tendering; once tenders are daily and response windows matter, the 204 earns its keep quickly.

An order asks for goods; a tender asks for a decision, on a clock. The 204 works when both sides treat acceptance — not transmission — as the moment a load becomes real, and when the detail in the tender is the truth about the freight. At SignalEDI, we treat the 204 as the start of a provable chain — tender, answer, status, invoice — because freight disputes are won by the side that kept the documents in order.

— Chris, founder of SignalEDI

The EDI 862, Decoded: A Shipping Schedule Is the Call to Ship, Not Another Forecast

challan116-ux — Mon, 02 Nov 2026 14:26:30 +0000

The EDI 862 · Shipping Schedule is the document a buyer sends when a forecast stops being a plan and becomes an instruction to ship. Where the 830 · Planning Schedule with Release Capability looks weeks or months ahead and separates what might be needed from what a supplier may start on, the 862 works on the short horizon — days, sometimes hours — and tells the supplier exactly what to ship, in what quantity, and when it must arrive. In a just-in-time flow, the 862 is the last word before goods move.

That short horizon is what makes the 862 both powerful and unforgiving. There is no time to email back and forth clarifying a quantity, and no slack to absorb a schedule that was read as information instead of instruction. If the 830 is a promise about preparation, the 862 is a promise about a truck.

What is the EDI 862 · Shipping Schedule?

The 862 is an X12 transaction set a buyer uses to communicate firm shipping requirements to a supplier. It carries, item by item, the quantities to ship and the dates and times they are required, usually against a schedule the two sides have already been planning with the 830 · Planning Schedule with Release Capability.

Three ideas define it:

Firm quantities. Unlike a forecast, the quantities in an 862 are requirements. The supplier is expected to ship them, not to plan around them.
Precise timing. The 862 typically specifies a required arrival or shipment date — and in just-in-time manufacturing, often a time window — because the goods are feeding a production line or a cross-dock that cannot hold buffer stock.
Cumulative context. Like the 830, the 862 sits inside a cumulative flow: what has already shipped and been received matters, because the new schedule is calling off a running total, not starting from zero each time.

An 862 usually replaces or refines the near-term portion of the most recent 830. It does not renegotiate the relationship; it executes it.

How is the 862 different from the 830, the 850, and the 856?

These four documents form one chain, and confusing any two of them breaks it:

The 830 · Planning Schedule with Release Capability forecasts demand over a longer horizon and authorizes a supplier to prepare — buy material, fabricate — within its release zone. It plans.
The 862 · Shipping Schedule firms up the near term and authorizes actual shipments. It ships.
The 850 · Purchase Order is a standalone firm order with commercial terms — price, terms, ship-to — for buyers and items that do not run on a repeating schedule. Scheduled flows often do not use an 850 at all for the scheduled items.
The 856 · Ship Notice / ASN flows the other way: the supplier sends it to say what actually shipped. The 862 says what must ship; the 856 says what did.

A useful shorthand: the 830 says "get ready, and here is roughly how much," the 862 says "ship this much, arriving then," and the 856 answers "here is what is on the truck." When a supplier asks whether a document is a heads-up or a commitment, the 862 is a commitment.

Why do buyers use an 862 instead of just sending purchase orders?

Because in a repeating manufacturing relationship, a fresh 850 · Purchase Order for every shipment would bury both sides in order administration for demand they already planned together. The schedule does the planning once, in the 830, and the 862 then calls shipments off that plan with minimal overhead.

The deeper reason is just-in-time production. A plant that holds hours, not weeks, of inventory cannot wait for an order cycle. It needs a lightweight, frequent, machine-readable way to say "the line will need this on Thursday morning" — and to change that instruction on Wednesday if the line's plan changes. That is exactly the job the 862 was built for, which is why it is most common in automotive and other high-volume manufacturing supply chains.

Where do 862 flows usually break?

The first break is the schedule treated as advisory. A supplier files the 862 alongside the forecast, plans loosely around it, and discovers it was a firm requirement only when the buyer's line stops or a premium-freight bill arrives. The fix is the same discipline as the 830, one step firmer: everyone who touches the document needs to know that an 862 quantity is a ship instruction, not a planning hint.

The second break is the missed update. An 862 flow lives on cadence — daily is common — and each new schedule can change the near-term requirement. If a supplier's system fails to load one day's schedule, or loads it after the shipping cutoff, the supplier ships yesterday's requirement with complete confidence. Monitoring that a schedule arrived and was applied, not just that a file was received, is the control that catches this.

The third break is cumulative-quantity drift, inherited from the 830 flow. If the two sides disagree about what has already shipped and been received, the quantity the 862 appears to require can be wrong even when the document itself is perfect. The schedule calls off a running total; a corrupted running total corrupts every call-off after it.

The fourth break is the timing window read as a date. In just-in-time flows, "Thursday" often really means a specific window on Thursday tied to a line sequence or a dock appointment. A shipment that arrives on the right day but outside its window can be functionally late — refused, rescheduled, or charged back — to the surprise of a supplier whose system only stored the date.

What should you check in an 862 flow?

Four checks keep a shipping schedule honest:

First, instruction clarity: does the supplier's system treat an 862 as a firm ship requirement, visually and operationally distinct from a forecast?

Second, cadence monitoring: is each expected schedule confirmed as received and applied before the shipping cutoff it governs, with an alarm when one is missing?

Third, cumulative reconciliation: do both sides agree on shipped and received totals before the next schedule's quantities are trusted?

Fourth, window fidelity: are required times stored and planned as times or windows where the buyer specified them, not flattened to dates?

A flow that runs those checks turns the 862 from a daily file into what it is meant to be: the reliable last word before goods move.

Frequently asked questions

Is an 862 · Shipping Schedule a purchase order?
No. An 850 · Purchase Order is a standalone firm order with commercial terms. An 862 is a firm shipping instruction inside an existing scheduled relationship — it authorizes shipments against a plan the 830 · Planning Schedule already established, rather than creating a new order.

What is the difference between the EDI 830 and the EDI 862?
The 830 · Planning Schedule with Release Capability forecasts over a longer horizon and authorizes preparation. The 862 · Shipping Schedule works the short horizon and authorizes actual shipments. Many manufacturing relationships run both: the 830 to plan, the 862 to ship.

How often is an 862 sent?
Frequently — daily is common in just-in-time flows, and some relationships update more often when production plans change. Each new schedule refines or replaces the near-term requirement, which is why missing one is a serious break.

What happens after an 862 is shipped against?
The supplier sends an 856 · Ship Notice / ASN describing what actually shipped, and later an 810 · Invoice for it. The buyer compares the 856 against the 862 requirement — that comparison is where short, late, and out-of-window shipments surface.

Does a small supplier need the 862?
Only if it serves a buyer running a scheduled, just-in-time relationship. For ordinary ordered goods, an 850 · Purchase Order plus an 856 · Ship Notice covers the flow more simply. The 862 earns its keep when shipments are called off a plan instead of ordered one by one.

A forecast gives a supplier time to prepare; a shipping schedule takes that preparation and spends it. The 862 works when both sides treat it with the seriousness its horizon demands — firm quantities, precise windows, and no schedule left unapplied. At SignalEDI, we treat the 862 as an instruction document, not a reporting document — because by the time it arrives, the next move belongs to a truck, not a planner.

— Chris, founder of SignalEDI

The EDI 830, Decoded: A Planning Schedule Is a Forecast With a Promise Attached

challan116-ux — Sun, 01 Nov 2026 14:28:00 +0000

The EDI 830 · Planning Schedule with Release Capability is the document a buyer sends when it wants a supplier to plan ahead — and, in the same document, to release some of that planned work for real. It carries a forecast of material requirements over time, and it marks which parts of that forecast the supplier is authorized to act on now: to buy material, to fabricate, or to ship. It is the middle ground between a guess about the future and a firm purchase order, and that middle ground is exactly where supplier relationships get made or broken.

Most of the confusion around the 830 comes from treating it as one thing. It is two things in one envelope: a planning horizon that says "this is roughly what we will need," and a release zone that says "this much of it you may start on today." Confusing the two is how a supplier ends up holding material for orders that never arrive, or a buyer ends up short because nobody was authorized to start.

What is the EDI 830 · Planning Schedule with Release Capability?

The 830 is an X12 transaction set a buyer uses to communicate planning and release information to a supplier. It tells the supplier, item by item and period by period, how much material the buyer expects to need, and it separates that demand into zones of commitment.

The three ideas inside it are worth keeping distinct:

Forecast requirements. Quantities the buyer expects to need in future periods, for planning purposes. These are not orders yet, and they will change.
Release requirements. Quantities the buyer authorizes the supplier to act on now — to procure raw material, to fabricate finished goods, or to ship against a schedule. Release authorization is the "release capability" in the document's name.
Cumulative and shipped quantities. What has already been received against the schedule, so both sides can compute what remains open rather than arguing about it from separate spreadsheets.

The 830 usually covers a rolling horizon — weeks or months out — and it is re-sent regularly as the horizon rolls forward. Each new 830 supersedes the previous one for the periods it covers, which is why the document's timing and version discipline matter as much as its contents.

How is the 830 different from the 850, the 862, and the 846?

The numbers sit close together and the documents overlap, which is why they get mixed up. Their jobs are different:

The 850 · Purchase Order is a firm order: buy this, at this price, by this date. It creates a commercial commitment.
The 830 · Planning Schedule with Release Capability is a forecast plus staged authorization. It lets the supplier prepare and, within the release zone, start work before a firm order exists.
The 862 · Shipping Schedule is the firmer, shorter-horizon cousin: it authorizes actual shipments against a schedule, often in a just-in-time manufacturing flow. Where the 830 plans and releases, the 862 ships.
The 846 · Inventory Inquiry/Advice reports stock on hand. It tells you what exists; the 830 tells you what is expected to be needed.

A useful shorthand: the 846 describes inventory, the 830 plans production against a forecast, the 862 calls shipments off that plan, and the 850 orders goods outright. When a supplier asks "do you want me to build this, ship this, or just know about it?" — the answer is whichever document arrived, and the 830 is the one that can mean all three in different zones of the same file.

Why do buyers send forecasts at all?

Because lead times are longer than order cycles. A supplier that only learns about demand when a firm 850 arrives cannot order raw material, book capacity, or staff a line in time — especially for items with long procurement lead times or custom components. The forecast gives the supplier a planning signal months out; the release zone gives it permission to spend money against part of that signal without waiting for the firm order to catch up.

That is also why the 830 is most at home in manufacturing supply chains — automotive, electronics, industrial equipment — where a buyer and a supplier run a repeating, high-volume relationship and the cost of a stock-out or an idle line dwarfs the cost of planning. It is less common in one-off spot buying, where a plain 850 does the job.

Where do 830 flows usually break?

The first break is the forecast treated as an order. A supplier reads the full horizon as a commitment, builds to the forecast, and then the buyer's demand shifts — as forecasts do — and the supplier is left with finished goods nobody ordered. The fix is contractual as much as technical: the release zone, not the forecast zone, is the authorization, and both sides need to agree in writing on what each zone permits before the first 830 flows.

The second break is the stale schedule. An 830 is only useful if it arrives on its cadence and supersedes the last one cleanly. When a buyer sends schedules irregularly, or a supplier's system keeps applying an old schedule alongside a new one, both sides plan against different numbers and discover the difference at the worst possible moment — when a shipment is due.

The third break is cumulative-quantity drift. The 830's shipped and received quantities are supposed to keep both sides in agreement about what is already done. When one side's system resets its cumulative counters, or counts a shipment the other side never recorded, the "remaining" quantity in the next schedule is wrong in a way that looks authoritative because it arrived in an official document. Reconciling cumulative quantities on a regular cadence — not just when something breaks — is the unglamorous control that keeps the whole schedule honest.

The fourth break is the silent change. A forecast quantity changes between schedules, and nobody flags it because the document looks routine. In a high-volume flow, a 20 percent swing in a forecast period should be a conversation, not a line item. The systems that handle this well surface material changes between schedule versions instead of quietly overwriting them.

What should you check in an 830 flow?

Four checks keep a planning schedule useful:

First, zone discipline: does every quantity in the document sit clearly in a forecast zone or a release zone, and does the supplier's system enforce the difference — planning against the forecast, spending only against the release?

Second, supersession: does each new 830 cleanly replace the previous one for its horizon, with no overlap between old and new schedules in the receiving system?

Third, cumulative reconciliation: do both sides agree on what has already shipped and been received, before the next schedule's remaining quantities are trusted?

Fourth, change visibility: when a forecast moves materially between versions, does someone see it and decide, rather than the system silently absorbing it?

A flow that runs those checks turns the 830 from a document that arrives into a schedule both sides actually plan against.

Frequently asked questions

Is an 830 · Planning Schedule a purchase order?
No. An 850 · Purchase Order is a firm order. An 830 carries a forecast for planning plus release authorization for part of that forecast. Only the release zone authorizes the supplier to act, and only to the extent the two sides agreed that zone permits.

What does "release capability" mean?
It means the document can authorize action, not just share information. A release can permit the supplier to procure material, fabricate goods, or ship — depending on the release type and the agreement behind it. The forecast alone authorizes nothing.

How is the 830 different from the 862 · Shipping Schedule?
The 830 plans and releases over a longer horizon; the 862 is the shorter-horizon, firmer schedule that authorizes actual shipments, typically in just-in-time flows. Many supplier relationships run both: the 830 for planning, the 862 for shipping.

How often should an 830 be sent?
On a fixed cadence both sides can rely on — weekly is common — with each new schedule superseding the last for its horizon. Irregular schedules are where stale-plan failures start.

Does a small supplier need the 830?
Usually only when it serves a buyer with a repeating, forecast-driven manufacturing relationship. For one-off or spot orders, a firm 850 is simpler and clearer. The 830 earns its keep when lead times force planning ahead of firm orders.

A forecast that nobody is authorized to act on is just a newsletter, and an authorization nobody planned for is just a surprise. The 830 exists because real supply chains need both at once: a view of what is coming, and permission to start on part of it today. At SignalEDI, we treat a planning schedule as a commitment document in the release zone and a planning document everywhere else — because blurring that line is how good supplier relationships quietly turn into inventory disputes.

— Chris, founder of SignalEDI

The EDI 944, Decoded: A Warehouse Stock Transfer Receipt Advice Is How a Transfer Becomes True

challan116-ux — Sat, 31 Oct 2026 13:26:20 +0000

The EDI 944 · Warehouse Stock Transfer Receipt Advice is the receiving warehouse's answer to a stock transfer. It reports what actually arrived at the receiving location — which products, in what quantities, in what condition — against what the sending location said it shipped in the 943 · Warehouse Stock Transfer Shipment Advice. Until the 944 comes back and matches, a transfer is a claim, not a fact.

Yesterday's document in this series, the 943, is the promise: stock has left one location and is headed to another. The 944 is the proof. It is the moment inventory stops being in transit on paper and becomes stock the receiving warehouse can put away, count, and sell against — or the moment a discrepancy gets named while the shipment is still identifiable.

What is the EDI 944 · Warehouse Stock Transfer Receipt Advice?

The 944 is an X12 transaction set used by a warehouse or receiving facility to advise a depositor or sending location that a stock transfer has been received. It confirms receipt of the transferred goods and reports the quantities and condition as received, not as shipped.

Think of the chain it completes:

The 943 · Warehouse Stock Transfer Shipment Advice says stock has left the sending location and is on its way.
The 944 · Warehouse Stock Transfer Receipt Advice says what the receiving warehouse actually received.
The 940 · Warehouse Shipping Order tells a warehouse to ship goods out to a customer.
The 945 · Warehouse Shipping Advice confirms what a warehouse shipped out on that instruction — the outbound mirror of the 944's inbound job.
The 846 · Inventory Inquiry/Advice reports stock levels — and it is only trustworthy if pairs like the 943/944 are closed honestly on both ends.

The 944 is not a payment document and it is not a customer document. No buyer is waiting on it and no invoice should be created from it. Its job is internal truth: two locations that both hold the same company's stock should end a transfer agreeing about what moved.

What does a 944 actually contain?

At the header, the 944 identifies the receipt: the receipt advice number, the date the goods were received, the receiving location, and references that tie it back to the original transfer — most importantly the shipment advice number from the matching 943, so the two documents can be paired automatically rather than by someone's memory.

At the line level, each item reports the product identifier, the quantity received, and the unit of measure. Where the received quantity differs from the shipped quantity, implementations carry the discrepancy and, in mature flows, a reason: short shipment, damage in transit, or a mis-pick at the sending end.

Receipt condition matters too. Goods that arrive damaged are received, but they are not available stock. A 944 that books damaged cases as good inventory has not confirmed a transfer; it has created a future stock-out with extra steps.

Why is the 944 different from the 945 · Warehouse Shipping Advice?

The numbers sit next to each other and the names sound alike, which is exactly why they get confused. Their directions are opposite.

The 945 looks outward. It tells a depositor what a warehouse shipped to a customer on a 940 · Warehouse Shipping Order — proof that an outbound instruction was carried out.

The 944 looks inward and sideways. It tells a sender what a receiving warehouse took in from a transfer — proof that an internal move landed. No customer order exists anywhere in the 944's story. If the 945 answers "did we ship what we were told to ship?", the 944 answers "did we receive what we were told was coming?"

Where do 944 flows usually break?

The first break is the 944 that never gets sent. The goods are on the shelf, the receiving warehouse is picking from them, and the sending location still shows the stock as in transit because no receipt advice ever closed the transfer. Every report that reads the documents instead of the shelves now disagrees with reality, and the argument gets settled by a cycle count weeks later.

The second break is the rubber-stamp 944 — a receipt advice generated by copying the 943's quantities instead of counting what arrived. This is worse than no 944 at all, because it closes the loop with false confidence. The discrepancy the document exists to surface — 90 arrived, 100 were shipped — gets absorbed silently into inventory, where it will surface later as a stock-out on a product the system swears is available.

The third break is a unit-of-measure mismatch at receipt. The 943 shipped cases; receiving books eaches; the 944 reports a number that is technically accurate and practically meaningless against the shipped quantity. Pairing the documents line by line only works if both ends agree on what one unit means, in writing, before the first transfer.

What should you check in a 943/944 loop?

Three checks keep the receiving end honest:

First, pairing, from the other side: every 944 should reference a real 943, and every 943 older than its expected transit time should have a 944 chasing it. An unpaired document in either direction is an open exception, not paperwork in progress.

Second, counted-not-copied: quantities on the 944 must come from the receiving count, not from the 943. If your system pre-fills the receipt from the shipment advice and receiving never edits it, you do not have a receipt process — you have a photocopier, and your discrepancies are being filed where nobody will ever look for them.

Third, condition and availability: received stock should enter available inventory only to the extent it arrived usable. Damaged or quarantined quantities belong in the 944 too, recorded as received-but-not-available, so the sender sees the full picture and the receiver never sells stock it cannot pick.

A flow that runs those checks turns the 944 from a formality into the control that keeps multi-location inventory believable.

Frequently asked questions

Is the 944 · Warehouse Stock Transfer Receipt Advice the same as the 945 · Warehouse Shipping Advice?
No. The 945 confirms an outbound shipment to a customer against a 940 order. The 944 confirms an inbound stock transfer against a 943 advice. Opposite directions, different document pairs.

Who sends the 944 and who receives it?
The receiving warehouse or facility sends it; the depositor, manufacturer, or sending location that issued the 943 receives it.

What document does a 944 answer?
The 943 · Warehouse Stock Transfer Shipment Advice. The 944 should reference the 943's shipment advice number so the pair can be matched automatically.

What happens if the received quantity differs from the shipped quantity?
Report what was actually received, with the difference named — short shipment, damage, or mis-pick. Copying the shipped quantity into the 944 hides the discrepancy inside inventory, where it surfaces later as an unexplained stock-out.

Does a single-warehouse business need the 944?
Usually not. Like the 943, it earns its keep when inventory moves between locations — multiple warehouses, a manufacturer shipping into a 3PL, or a 3PL rebalancing stock between facilities.

A transfer is not finished when the truck is unloaded; it is finished when both ends agree, in writing, about what moved. At SignalEDI, we treat an unclosed 943/944 pair as an open exception rather than a delay — because inventory records that disagree with the shelf do not stay a warehouse problem for long. They become a promise made to a customer that nobody can keep.

— Chris, founder of SignalEDI

The EDI 943, Decoded: A Stock Transfer Shipment Advice Is Inventory Telling the Next Warehouse It Is Coming

challan116-ux — Fri, 30 Oct 2026 13:27:09 +0000

The EDI 943 · Warehouse Stock Transfer Shipment Advice is the advance notice that inventory is moving between locations. A depositor, manufacturer, or sending facility uses it to tell a receiving warehouse that a transfer shipment has been made and is on its way — what products, in what quantities, from where, by which carrier, and when to expect them. The receiving warehouse answers later with the 944 · Warehouse Stock Transfer Receipt Advice, confirming what actually arrived.

If the 940 · Warehouse Shipping Order and the 945 · Warehouse Shipping Advice are about goods leaving a warehouse for a customer, the 943 and 944 are about goods moving sideways — from one warehouse to another, from a manufacturer to a 3PL, or between facilities that both hold your stock. That sideways move is where inventory records most quietly go wrong.

What is the EDI 943 · Warehouse Stock Transfer Shipment Advice?

The 943 is an X12 transaction set used by a depositor or an agent of the depositor to advise a recipient that a transfer shipment has been made. It gives the receiving location detailed information about product being shipped to that location, before the truck arrives.

Think of the chain it belongs to:

The 943 · Warehouse Stock Transfer Shipment Advice says stock has left the sending location and is headed to the receiving warehouse.
The 944 · Warehouse Stock Transfer Receipt Advice says what the receiving warehouse actually received.
The 940 · Warehouse Shipping Order tells a warehouse to ship goods out to a customer.
The 945 · Warehouse Shipping Advice confirms what a warehouse shipped out on that instruction.
The 846 · Inventory Inquiry/Advice reports stock levels — and it is only trustworthy if transfers like the 943/944 pair are recorded correctly on both ends.

The 943 is not a sales document. No customer ordered anything in it, and nothing in it should create an invoice. It is an internal movement made visible between systems, so the inventory that left one building and the inventory that enters another stay the same inventory in the records.

What does a 943 actually contain?

At the header, the 943 identifies the shipment: a shipment advice number that ties this transfer together, the ship date, the sending location, the receiving location, and the carrier and transportation details for the move.

At the line level, each item reports the product identifier, the quantity shipped, and the unit of measure. Where traceability matters, implementations also carry lot or serial details. Quantities and identifiers have to mean the same thing on both ends. A 943 that ships cases to a warehouse that receives in eaches has not transferred inventory; it has created a discrepancy that the 944 will either expose or, worse, quietly absorb.

Weight, carton, and shipment-reference details help the receiver plan. A warehouse that knows what is coming, and roughly when, can schedule dock time and labor and stage put-away. A warehouse that finds out when the truck backs in cannot.

Why is the 943 different from the 856 · Ship Notice / ASN?

Both documents are advance notices of a shipment, which is why they get confused. Their audiences and jobs are different.

The 856 · Ship Notice / ASN goes to a buyer — usually a retail customer — under a compliance program, with deadlines and chargebacks attached. It says: your order is coming, in these cartons, arriving then.

The 943 goes to a warehouse. It says: your stock is coming. There is no buyer, no purchase order being fulfilled, and no customer promise being made. The promise is internal: the receiving location should be able to plan receiving, and the sender's and receiver's inventory records should agree once the matching 944 comes back.

The 943 has one more job the 856 never does. It can also be used by a manufacturer to authorize a warehouse to accept a return from a customer — telling the warehouse, in advance and in writing, that goods coming back to it are expected and should be received rather than refused.

Where do 943 flows usually break?

The first break is the transfer nobody closes. The 943 is sent, the sending location decrements its stock, and the receiving location is supposed to increment its stock when the 944 confirms receipt. If the 944 never arrives — or arrives and is never matched to the 943 — the goods sit in a record-keeping limbo: gone from one warehouse, never added to the other, while physically sitting on a shelf. Available-to-promise then understates stock you actually own, or, if both sides count the transfer, overstates it and sells inventory twice.

The second break is a quantity or unit-of-measure mismatch that gets received silently. The truck carries 90, the 943 says 100, and receiving books 100 because that is what the document said. The 944 exists precisely to prevent this: it should report what was actually received, including the discrepancy, so the difference is investigated while the shipment is still identifiable — not discovered weeks later in a cycle count.

The third break is timing. A 943 that arrives after the goods do is not an advice at all; it is a reconstruction. The receiving value of the document is that it precedes the shipment, so exceptions — a transfer for a location that should not hold that product, quantities that exceed what the receiver can store — can be raised before receiving, not after put-away.

What should you check in a 943/944 loop?

Three checks keep a transfer honest:

First, pairing: every 943 should eventually have a matching 944. A 943 that stays unpaired past the expected transit time is an open incident, not paperwork in progress.

Second, agreement: quantities, product identifiers, and units of measure on the 944 versus the 943, line by line. Any difference needs a named reason — damage in transit, a short shipment, a mis-pick at the sending location — recorded against the transfer, not absorbed into a stock adjustment nobody can explain later.

Third, timing on both ends: stock should leave the sender's available balance when it ships and enter the receiver's available balance when it is received — not both at the same moment, and not before receipt. The in-transit gap is real inventory in a real place: on a truck. Good systems show it as in transit; weak systems either double-count it or lose it.

A flow that runs those checks turns a stock transfer from the easiest place to lose inventory into a documented move that both warehouses can prove.

Frequently asked questions

Is the 943 · Warehouse Stock Transfer Shipment Advice the same as the 856 · Ship Notice / ASN?
No. The 856 notifies a buyer that their order is coming. The 943 notifies a receiving warehouse that transferred stock is coming. Different recipient, different purpose, no customer order involved.

Who sends the 943 and who receives it?
A depositor, manufacturer, or sending facility sends it; the receiving warehouse or 3PL location receives it. The receiver later answers with the 944 · Warehouse Stock Transfer Receipt Advice.

What document answers a 943?
The 944 · Warehouse Stock Transfer Receipt Advice, which reports what was actually received — including any discrepancy against what the 943 said was shipped.

What happens if the 944 never comes back?
The transfer stays unclosed. The sending location has removed the stock and the receiving location has not confirmed adding it, so inventory records disagree with physical stock. Treat an aging unpaired 943 as an exception to resolve, not a delay to ignore.

Does a single-warehouse business need the 943?
Usually not. The 943 earns its keep when inventory moves between locations — multiple warehouses, a manufacturer shipping into a 3PL, or a 3PL rebalancing stock between its own facilities. With one location, there is no transfer to advise.

Inventory that moves without a document is inventory you will eventually argue about. At SignalEDI, we treat the 943/944 pair as a closed loop — every transfer advice tracked until its receipt advice matches it — because phantom stock created by an unclosed transfer is sold, promised, and charged back exactly like real stock, right up until someone tries to pick it.

— Chris, founder of SignalEDI

The EDI 945, Decoded: A Warehouse Shipping Advice Is Proof, Not Paperwork

challan116-ux — Thu, 29 Oct 2026 13:26:21 +0000

The EDI 945, Decoded: A Warehouse Shipping Advice Is Proof, Not Paperwork

The EDI 945 · Warehouse Shipping Advice is the document a warehouse or 3PL sends back to the seller after it ships an order, reporting what actually left the dock — which items, in what quantities, under which carrier and tracking details. It answers the 940 · Warehouse Shipping Order. The 940 is the instruction; the 945 is the evidence that the instruction was, or was not, carried out exactly as sent.

If you outsource fulfillment, the 945 is the first truthful record of a shipment. Everything downstream — the 856 · Ship Notice / ASN to the buyer, the 810 · Invoice, the inventory balance — should be built from it, not copied forward from the original order.

What is the EDI 945 · Warehouse Shipping Advice?

The 945 is an X12 transaction set sent by a warehouse, distribution center, or 3PL to the depositor — the seller whose goods it stores and ships. It closes the loop opened by the 940.

Think of the chain it completes:

The 850 · Purchase Order says what the buyer ordered from the seller.
The 940 · Warehouse Shipping Order says what the seller told the warehouse to ship.
The 945 · Warehouse Shipping Advice says what the warehouse shipped.
The 856 · Ship Notice / ASN tells the buyer what is coming, based on that shipped reality.
The 810 · Invoice bills for what shipped, not for what was merely ordered.

When the 945 matches the 940 line for line, the rest of the flow is routine. When it does not — a short pick, a substitution, a split shipment, a different carrier — that difference is not a warehouse footnote. It is a change to what the buyer should be told and what they should be billed.

What does a 945 actually contain?

At the header, the 945 identifies the shipment being reported: the warehouse, the depositor, the shipment and order references that tie it back to a specific 940, the ship date, and the carrier and service level actually used.

At the line level, each item reports the quantity shipped — and, in implementations that use it well, the quantity ordered alongside it, so a shortfall is visible in the document itself rather than discovered by subtraction later. Product identifiers should match the identifiers on the 940, in the same unit of measure. A 945 that reports cases where the 940 ordered eaches has not confirmed anything; it has created a second translation problem.

Many implementations also carry carton, weight, and tracking or bill-of-lading references. Those details matter because they are the link between the digital record and a physical box a carrier can find. An ASN built without them is a promise; an ASN built from them is a report.

Why is the 945 different from the 856 · Ship Notice / ASN?

This is the confusion that breaks otherwise good flows. The 945 and the 856 can look similar — both describe a shipment — but they have different senders, different recipients, and different jobs.

The 945 goes from the warehouse to the seller. It is an internal confirmation inside the fulfillment relationship: we shipped this, for you, like this.

The 856 goes from the seller to the buyer. It is an external commitment to a trading partner, often under a compliance program with deadlines and chargebacks: this is what is coming to you.

The seller's job in the middle is reconciliation. Read the 945, compare it to the 940 and the underlying 850, resolve any difference, and only then build the 856 from the reconciled result. Skipping that middle step — generating the ASN straight from the order — is how buyers get told a full order shipped when the warehouse had already reported, clearly, in the 945, that it did not.

Where do 945 flows usually break?

The first break is the unexamined confirmation. The 945 arrives, gets filed, and nobody compares it to the 940. A line shipped short, or not at all, travels onward into the ASN and the invoice as if it had shipped in full. The buyer discovers the truth at receiving — the worst possible place, with a claim, a chargeback, and a receiving team holding physical evidence that contradicts your paperwork.

The second break is the partial shipment treated as complete. Warehouses split shipments for ordinary reasons: stock in two locations, a back-ordered line, a carrier cutoff. A good 945 flow reports each partial shipment as its own advice, clearly linked, so the seller can decide whether the buyer gets one ASN per shipment or a consolidated view. A weak flow overwrites the first advice with the second, and the record of what shipped first quietly disappears.

The third break is timing. A 945 that arrives days after the truck leaves has lost most of its value. The ASN deadline is already running, the buyer may already be asking where the shipment is, and the window to correct a carrier or quantity mistake before it becomes a compliance failure has closed. The advice has to be prompt to be useful — same-day, tied to the ship event, not batched as an end-of-week summary.

What should you check when a 945 arrives?

Three comparisons, in order, catch most of the damage:

First, quantities: shipped versus instructed on the 940, line by line, in the same unit of measure. Any difference needs a named reason — short stock, damage, a cancelled line — not just a smaller number.

Second, identity: carrier, service level, and tracking references versus what the order required. A shipment that went out on the wrong service level can be a compliance failure even when every item is correct.

Third, completeness: does this 945 close the 940, or is more still to ship? An open remainder should stay visibly open — as a back order, a second shipment, or a cancellation the buyer agrees to — rather than fading into an assumption that it will sort itself out.

A flow that runs those three checks automatically, and holds the ASN until they pass or a person resolves them, turns the 945 from paperwork into control.

Frequently asked questions

Is the 945 · Warehouse Shipping Advice the same as the 856 · Ship Notice / ASN?
No. The 945 is the warehouse reporting to the seller what it shipped. The 856 is the seller telling the buyer what is coming. The 945 is the source; the 856 should be built from it after reconciliation.

Who sends the 945 and who receives it?
The warehouse, distribution center, or 3PL sends it; the seller or brand owner whose goods were shipped receives it.

What document does a 945 answer?
The 940 · Warehouse Shipping Order. The 940 instructs; the 945 confirms what was actually done about that instruction.

What happens if a 945 reports less than the 940 ordered the warehouse to ship?
That is a short shipment. The seller should not build a full-quantity ASN or a full-quantity invoice from the original order. Reconcile first: notify the buyer accurately, decide whether the remainder ships separately or is cancelled, and bill only for what shipped.

Does every business need a 945?
Only businesses that use a separate warehouse or 3PL need this specific loop. If you ship from your own dock, your own shipping system is the source of truth — but you still need the same discipline: build the ASN and invoice from what actually shipped, not from what was ordered.

An instruction without a confirmation is just a hope with a control number. At SignalEDI, we treat the 940/945 loop as a first-class part of the order flow — the 945 is reconciled against the order before the ASN and invoice are built, because a short pick reported honestly on day one is a manageable conversation, and the same short pick discovered by the buyer at receiving is a chargeback.

— Chris, founder of SignalEDI

The EDI 940, Decoded: A Warehouse Shipping Order Is an Instruction, Not a Suggestion

challan116-ux — Wed, 28 Oct 2026 13:26:45 +0000

The EDI 940 · Warehouse Shipping Order is the document a buyer or seller sends to a warehouse — often a 3PL — telling it exactly what to ship, to whom, and under what terms. It is not a purchase order and it is not a ship notice. The 850 · Purchase Order creates the commercial promise between buyer and seller; the 940 turns part of that promise into a physical instruction a warehouse can act on; the 945 · Warehouse Shipping Advice then reports back what the warehouse actually shipped.

If you use a third-party warehouse, the 940 is where your order stops being data in an ERP and becomes boxes on a dock. Errors here do not stay digital for long.

What is the EDI 940 · Warehouse Shipping Order?

The 940 is an X12 transaction set sent to a warehouse or distribution center directing a shipment. It identifies the ship-to party, the carrier and service level, the requested ship date, and, line by line, the items and quantities to pick.

Think of the chain it sits in:

The 850 · Purchase Order says what the buyer ordered from the seller.
The 940 · Warehouse Shipping Order says what the seller wants the warehouse to ship for that order.
The 945 · Warehouse Shipping Advice says what the warehouse shipped.
The 856 · Ship Notice / ASN tells the buyer what is coming.
The 810 · Invoice bills for what shipped and was accepted.

When those documents agree, fulfillment is routine. When the 940 disagrees with the 850 — wrong quantity, wrong ship-to, a line that was cancelled on an 860 · Purchase Order Change — the warehouse will faithfully ship the wrong thing, on time, with perfect paperwork.

What does a 940 actually contain?

At the header, the 940 carries the warehouse instruction: the depositor (the seller whose goods are stored), the ship-to name and address, carrier and routing instructions, and any special handling or reference numbers the warehouse needs to match the shipment back to the original order.

At the line level, each item carries the product identifier — usually the buyer's item number or UPC alongside the seller's SKU — the quantity to ship, and the unit of measure. That unit-of-measure detail is where many 940s quietly fail: an order for 12 eaches sent as 12 cases is not a small error, it is a twelvefold shipment and a very expensive return.

Some implementations also carry lot, expiration, or pallet instructions, and order-level notes the pick team actually reads. A 940 that relies on a free-text note to carry a critical instruction — a different label, a retailer compliance requirement — is fragile, because notes are the first field downstream systems drop.

Why does the 940 matter if the warehouse already has a portal or API?

Because the instruction still has to be unambiguous, acknowledged, and traceable. A portal entry, an API call, and a 940 all do the same job, but the discipline is identical: the warehouse should only act on an instruction it can match to an order, confirm back with a 945, and reconcile later against the ASN and invoice.

That confirmation loop is the point most often missed. Sending a 940 and hearing nothing is not success — it is an unacknowledged instruction. Mature flows treat the 945 · Warehouse Shipping Advice as mandatory: it closes the loop on what was picked, what was short, and which carrier and tracking details apply, so the seller can build an accurate 856 and 810 instead of copying the original order forward and hoping the dock agreed.

Where do 940 flows usually break?

The first break is the stale instruction. An order changes — an 860 amends quantity or cancels a line — but the 940 already sent to the warehouse is never updated or withdrawn. The warehouse ships the original instruction correctly and everyone else calls it a warehouse error. Version discipline matters: a changed order needs a changed warehouse instruction, explicitly linked to the one it replaces.

The second break is inventory the seller assumed. The 940 instructs shipment of goods the warehouse does not have, in the lot or condition required, because the seller's available-to-promise figure and the warehouse's actual stock — the figure an 846 · Inventory Inquiry / Advice would report — had drifted apart. The result is a short pick discovered at the dock, too late to re-source calmly.

The third break is treating the 940 as a file to generate rather than a commitment to verify. If nobody checks the 945 against the 940, shortages, substitutions, and carrier changes surface only when the buyer files a claim or the invoice is disputed — weeks later, with worse evidence than the 945 offered on day one.

Frequently asked questions

Is the 940 · Warehouse Shipping Order the same as the 850 · Purchase Order?
No. The 850 is the buyer's commercial order to the seller. The 940 is the seller's fulfillment instruction to a warehouse. Different sender, different recipient, different job — the 940 exists because the party who sold the goods is often not the party holding them.

Who sends the 940 and who receives it?
The seller or brand owner sends it; the warehouse, distribution center, or 3PL holding their inventory receives it and acts on it.

What document answers a 940?
The 945 · Warehouse Shipping Advice. It reports what was actually shipped, in what quantities, and with what carrier details — the warehouse's counterpart to the seller's ASN discipline.

Does a 940 replace a warehouse's own WMS?
No. The 940 is the instruction that enters the warehouse management system; the WMS still runs picking, packing, and labeling. The EDI document is how the instruction arrives accurately and traceably, not how the dock does its work.

A warehouse will ship exactly what it is told to ship — which is why the telling has to be exact. At SignalEDI, we treat the 940/945 loop as a first-class part of the order flow, reconciled against the order and the ASN, because the cheapest fulfillment error is the instruction that gets checked before a box is taped shut.

— Chris, founder of SignalEDI