The most dangerous property of a delivery call-off is that nothing happens when it fails. Under the VDA convention a new call-off replaces the old one — and if a new call-off is not transmitted, the old one simply continues to apply. There is no error, no alarm, no gap in anyone's inbox. A supplier can spend a fortnight building to a schedule you superseded, and the first indication either party gets is a delivery that does not match what the line needs. The same holds for the reverse case: transmissions do not always contain every article, because call-offs are only sent for articles that changed, so silence is a legitimate state rather than a fault condition. Managing call-offs well is therefore mostly about making silence legible — knowing which schedule each supplier is actually working from, whether they acknowledged it, and whether their cumulative quantity agrees with yours. This covers generation, acknowledgement, shortfall detection and the recovery paths available once a gap appears. Request an enterprise demo to see it against your own call-off flow.
PLATFORM GUIDE · 2026
JIT Call-Off Management for Plant Supply
Generation, acknowledgement, shortfall detection and recovery — built around what the call-off standard actually does when something goes wrong, which is usually nothing at all.
ForecastPlanning horizonIndicative
Delivery call-offSchedule with cumulativesCommits material
Daily / JIT call-offTime-slot precisionCommits timing
Despatch call-offSent before pickupBinding
The Binding Hierarchy
Four layers, each narrowing what the supplier may still change. Most call-off problems trace to a mismatch about which layer a given number came from — a supplier treating a forecast quantity as committed, or a planner assuming a daily call-off carries the finality of a despatch call-off.
01Delivery instruction / forecast schedule
The standard forecast delivery schedule carrying incoming cumulative quantities, or a delivery preview with requirement cumulatives inside a JIT process. Sets the planning horizon and the material commitment, not the hour.
Watch forSuppliers planning capacity from this and treating later layers as confirmation rather than instruction
02Daily call-off
Transmitted daily, functioning either as a forecast schedule with incoming cumulatives or as a delivery preview with requirement cumulatives within the JIT process — the distinction carried by a usage code at part level, not by the message type.
Watch forUsage codes being ignored downstream, so both variants get processed identically
03JIT call-off
Precise demand at time-slot level rather than daily granularity, communicating exact shipping times and quantities. Supplements the delivery schedule rather than replacing it — the two are read together.
Watch forJIT call-offs read in isolation from the schedule they supplement, producing quantity disputes
04Despatch call-off
The binding delivery call-off, typically issued the day before material is collected from the supplier. After this, the quantity and timing are fixed and any change is an exception rather than an amendment.
Watch forChanges attempted after this point being handled informally instead of as recorded exceptions
Silent Behaviours You Have to Design Around
These are documented, intentional properties of the standard — not bugs. Each one is reasonable in isolation and each one creates a failure mode that produces no error message anywhere.
A new call-off replaces the old one
And if a new call-off is not transmitted, the old one continues to apply. There is no expiry.
CreatesA supplier building indefinitely to a superseded schedule, with no signal to either side
Transmissions omit unchanged articles
Call-offs are only transmitted for articles that changed, so an absent part number is normal rather than missing.
CreatesGenuine transmission failures indistinguishable from correct silence
Full cancellation cannot be transmitted
Complete cancellation of a delivery call-off is not sendable by remote data transmission and has to be handled outside the message flow.
CreatesCancellations living in email while the system still shows an active commitment
Cumulative quantities reset periodically
The goods receipt cumulative resets to zero at the start of a new accumulation period, generally the change of year.
CreatesReconciliation breaking across the boundary if either side resets on a different date
Changes carry a new transmission identity
Any change to the daily call-off is transmitted under a new transmission identification rather than as an update to the previous one.
CreatesVersion confusion where the supplier holds two valid-looking transmissions and processes the wrong one
Call-off dates may mean arrival, not despatch
Under the recommendation the call-off date can implicitly refer to the arrival date rather than the shipping date.
CreatesA systematic offset equal to transit time, discovered only when someone reconciles by hand
The design principle that follows
Because the standard is silent on failure, your platform has to be noisy about it. Every call-off needs a state — issued, acknowledged, superseded, expired-by-policy — even though the message format has no concept of most of those. That state layer is the entire value of call-off management software, and it sits above the EDI rather than inside it.
If you cannot name which call-off each supplier is currently building to, you do not have a call-off process.
An enterprise demo runs your supplier set, message flows and acknowledgement data through the state model and shows which commitments are currently unconfirmed.
Cumulative Quantity Reconciliation
Cumulatives are the mechanism that makes call-offs self-correcting across a period — and the mechanism that hides a shortfall for weeks when the two sides disagree. Read both columns as a single ledger.
What you count
Received cumulativeGoods receipt quantity accumulated since period start
Required cumulativeTotal called off to date against this part
Open positionRequired minus received, from your side
Period startThe reset date you are counting from
What the supplier counts
Despatched cumulativeTotal shipped since their period start
Acknowledged cumulativeTotal they believe was called off
In transitDespatched but not yet received by you
Period startTheir reset date, which may not be yours
The three deltas worth alerting on
Required vs acknowledgedA schedule mismatch. The supplier is building to a different number than you called for — usually a superseded transmission.
Despatched vs receivedExplained by transit, or by material that never arrived. If it exceeds plausible transit time, treat it as a shortfall now rather than at period end.
Period start mismatchRare and severe. Every other comparison becomes meaningless, and it typically surfaces at year change when both sides reset independently.
Acknowledgement: The Missing Handshake
A call-off that has been transmitted is not a call-off that has been received, parsed and accepted. The gap between those states is where most silent failures live, and closing it is the highest-value single change available.
1IssuedTransmitted with a transmission identification. This is all most systems track.
2DeliveredConfirmed as arriving at the supplier's gateway. Transport-level, not business-level.
3ParsedStructurally valid and loaded into the supplier's planning system. Failures here are common and quiet.
4Business-acceptedThe supplier confirms they are building to this schedule. VDA messages generate responses used to acknowledge receipt, confirm business acceptance, or report exceptions — this is the state that matters.
5SupersededReplaced by a later transmission. Must be an explicit state, since the standard provides no expiry.
Measure acknowledgement latency per supplier as a standing metric. A supplier whose median time from issue to business acceptance is measured in days is a supplier whose commitments you cannot rely on — regardless of how good their on-time delivery figure looks, because that figure is calculated against whatever schedule they happen to be holding.
Shortfall Detection Points
Ordered by how early each one can fire. The bottom of this table is where most plants currently detect shortfalls, which is why most shortfalls become expedites. Our analytics and reporting module carries the watchlist.
← Swipe to see all columns →
| Detection point | What it catches | Lead time gained |
|---|---|---|
| Acknowledgement not received | Supplier is not building to your current schedule | Full production lead time |
| Required vs acknowledged cumulative | Quantity mismatch against a superseded transmission | Most of the lead time |
| Capacity confirmation missing | Supplier accepted the schedule but cannot meet it | Days |
| Despatch advice quantity below call-off | Short shipment, before the truck leaves | Full transit time |
| No despatch advice against a due call-off | Nothing shipped at all — the silent no-show | Transit time, if you check |
| Gate arrival without matching call-off | Version mismatch surfacing physically | Minutes to hours |
| Goods receipt below expected | Confirmed shortfall | None — this is the record |
| Period-end cumulative variance | Everything the above missed, weeks later | Negative. It is already history |
Recovery Paths, Costed
Once a shortfall is confirmed, these are the options. The point of the detection table above is to keep you in the top half of this one.
Reissue and reconfirmThe supplier was building to a stale schedule. Reissue, obtain explicit acknowledgement, and the gap closes within their normal lead time.Cost: none beyond the alert
Pull forward against cumulativeWhere the supplier is ahead on cumulative, bring a later call-off forward rather than raising a new demand. Uses commitment that already exists.Cost: minimal
Reallocate across plantsThe same supplier ships to several of your sites. Move stock between plants rather than raising an expedite against the supplier.Cost: internal transport
Partial delivery on split call-offSplit the call-off so the critical quantity ships immediately and the balance follows on the original schedule.Cost: extra transport leg
Premium freightDedicated or air movement of the shortfall. Effective and visible, and the line item that funds every improvement above it.Cost: high, and attributable
Resequence or stopReorder production around the missing part, or halt. Both propagate cost well beyond the original shortfall.Cost: the one you were avoiding
The VDA Message Set
What each message is for, and the equivalence that matters when your supply base spans regions. A fixed layout with one intended use per message is the point of the VDA family — a given code always means the same thing, with very little partner-specific creativity. Our integrations overview covers the connectivity surface.
VDA 4905Delivery call-off / delivery instructionThe forecast delivery schedule with cumulative quantities. ODETTE equivalent is DELINS. Record types run from 511 through to 519, with 515 carrying additional schedule information, 517 packaging materials data and 518 delivery call-off detail.
VDA 4915JIT call-offDemand at time-slot rather than daily level, communicating exact shipping times and quantities. Supplements the 4905 delivery planning rather than replacing it. EDIFACT equivalent is DELJIT.
VDA 4985Global DELJITThe successor to the legacy 4915 for exchanging just-in-time delivery information. If you are still on 4915, this is the migration ahead of you.
VDA 4984Global DELFORThe global delivery forecast message. Sits above the call-off layer, setting the planning horizon suppliers commit capacity against.
VDA 4916JIT / JIS call-offsWhere sequenced supply is in scope, this carries the sequence dimension alongside the timing one. Relevant to any part family delivered in build order.
Status codesCall-off and JIT sequencing statusCarried in the 4915 and 4985 messages for just-in-time and sequence-based supply. These are what make an acknowledgement state machine possible rather than aspirational.
Regional note: in the NAFTA region ANSI X12 message types are the norm rather than VDA, and OEM-specific subsets exist within the VDA standard itself — German OEMs may have slightly different requirements that upstream suppliers must accommodate. Design the platform around the semantics, not around one OEM's variant, or the second OEM you onboard becomes a rebuild.
See the State Layer on Your Own Call-Offs
An enterprise demo takes your supplier set, message types and current acknowledgement data, and shows which call-offs are unconfirmed, where cumulative quantities disagree, and which shortfalls were detectable weeks before they were found. Sits above your existing EDI rather than replacing it.
Call-off state machine
Acknowledgement tracking
Cumulative reconciliation
VDA and DELJIT native
Frequently Asked Questions
What is the difference between a delivery call-off and a JIT call-off?
The delivery call-off is the schedule — a forecast delivery plan carrying cumulative quantities, or a delivery preview with requirement cumulatives inside a JIT process. The JIT call-off supplements it with precision, communicating exact shipping times and quantities at time-slot rather than daily level. They are read together rather than as alternatives, which is why quantity disputes so often trace to one being processed without the other. In EDIFACT terms the pair maps roughly to DELFOR and DELJIT.
What happens if we fail to transmit a call-off?
Nothing visible, which is the problem. A new call-off replaces the old one, and if a new one is not transmitted the old one continues to apply — there is no expiry and no error. The supplier keeps building to the last schedule they received, quite correctly. This is why an explicit superseded state and a maximum age policy have to exist in your own system: the message standard will not tell you that a schedule has gone stale, because from its perspective it has not.
How do we cancel a call-off entirely?
Not through the message flow. Complete cancellation of a delivery call-off cannot be transmitted by remote data transmission and has to be handled by another route, typically a direct agreement with the supplier. The operational risk is that the cancellation then lives in an email while your system still shows an active commitment and the supplier's still shows a live schedule. Record the cancellation as an explicit state change on your side, with the out-of-band confirmation attached, or it will reappear as an unexpected delivery.
Why do cumulative quantities disagree at year end?
Because the goods receipt cumulative resets to zero at the start of a new accumulation period, generally at the change of year, and both sides have to reset on the same boundary for the comparison to survive. Where reset dates differ even slightly, every cumulative comparison across the boundary becomes meaningless and the discrepancy looks like a shortfall or an overage that never happened. Agree the accumulation period explicitly per supplier and check it before the boundary rather than after.
Does the call-off date mean shipping or arrival?
Check, because it varies and the recommendation allows the call-off date to refer implicitly to the arrival date. If one side reads it as a despatch date and the other as an arrival date, you have a systematic offset equal to transit time affecting every line — which typically shows up as a supplier who appears consistently early or consistently late by a suspiciously stable margin. It is worth confirming per supplier and per message variant rather than assuming a house convention holds.
How do we know a supplier actually received a call-off?
Through an acknowledgement, and specifically a business acceptance rather than a transport-level receipt. VDA messages generate responses used to acknowledge receipt, confirm business acceptance, or report exceptions — that response is the only reliable evidence that the supplier is building to your current schedule. Track acknowledgement latency per supplier as a standing metric; a supplier with a median measured in days has commitments you cannot rely on regardless of their delivery statistics.
Do we need to migrate off VDA 4915?
Eventually. The legacy 4915 is the predecessor of the 4985 Global DELJIT for exchanging just-in-time delivery information, and OEMs have been sequencing the migration for some time alongside the wider move to global message variants. There is no urgency to rebuild ahead of your OEM's own timeline, but new integration work should target the successor rather than extending the legacy. Design your internal model around call-off semantics rather than a specific message layout and the migration becomes a mapping exercise instead of a project.
Make the Silence Legible
Every call-off in an explicit state, acknowledgement tracked as business acceptance rather than transmission success, cumulative quantities reconciled continuously instead of at period end, and shortfalls detected while recovery is still cheap.
Sits above existing EDI · VDA and DELJIT native · Site-level configuration
August 13, 2026By Alex Rowan
All Blogs
