ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

DELFOR — Delivery Schedule Message (D.96A)

The DELFOR message carries a delivery schedule from a buyer to a supplier — firm short term plus mid- and long-term forecast — under the terms of a blanket contract.

Purpose

Per the official UN/CEFACT definition, DELFOR is "a message from buyer to supplier giving product requirements regarding details for short term delivery instructions and/or medium to long term product/service forecast for planning purposes according to conditions set out in a contract or order. The message can be used to authorize the commitment of labour and materials resources."

In practice, DELFOR is the workhorse of call-off flows in automotive and contract manufacturing. It blends a firm horizon (the upcoming weeks, which authorise production) with a forecast horizon (capacity planning). DELFOR steadily replaces one-off ORDERS for recurring SKUs.

Segment structure

A D.96A DELFOR message has three sections: a Header, a Detail, and a Summary. The Detail wraps a master loop SG4 (parties — typically Ship-To) which nests an item loop SG8 (LIN) repeatable up to 9,999 times, then a scheduled-quantity loop SG12.

Mandatory header segments: UNH M , BGM M , and DTM M .

Then come segment groups: SG1 RFF+DTM (references — typically the contract number), SG2 NAD+LOC with its sub-group SG3 CTA+COM (parties and contacts at message level).

Detail (delivery schedule)

The Detail section opens with a mandatory UNS M (qualifier D).

Then comes the SG4 loop (up to 500 occurrences) built around NAD M + LOC C + FTX C . Each SG4 typically describes a delivery point (NAD+CN Consignee) and nests:

  • SG5 DOC+DTM — documents/messages tied to the party.
  • SG6 CTA+COM — specific contacts.
  • SG7 TDT+DTM — transport details at delivery-point level.
  • SG8 — the item loop (up to 9,999 occurrences) with LIN M , PIA C , IMD C , MEA C , ALI C , GIN C , GIR C , LOC C , DTM C , and FTX C .
  • SG9 CTA+COM, SG10 RFF+DTM, SG11 TDT+DTM, SG13 RFF+DTM — at item-line level.

Inside SG8 sits DELFOR's business core: the SG12 loop (up to 200 occurrences) with QTY M + SCC C + DTM C . This is where the buyer expresses, line by line, the demand: this many units on this date, with that status (firm/forecast).

SG8 then also wraps PAC+MEA+QTY+DTM (SG14), PCI+GIN (SG15) and QVR+DTM (SG16) for quantity variances.

SG17 RFF+DTM closes the SG4 loop. Group SG18 (outside SG4, up to 9,999 occurrences) mirrors an item structure (LIN + sub-groups SG19 through SG31) for call-offs not explicitly tied to a delivery point.

Summary

The Summary section contains: UNS M , CNT , FTX , then UNT M .

Mandatory / conditional

Five structural items are strictly mandatory in every D.96A DELFOR:

  • UNH — opens the message.
  • BGM — gives the function (241 = Delivery schedule), number, and status.
  • DTM in the header — at least one date (the document date, DTM+137).
  • UNS+D — Header → Detail divider.
  • UNS+S — Detail → Summary divider, followed by UNT.

On the business side you also need at least one buyer/supplier NAD in the header (via SG2), at least one LIN (via SG8 or SG18), and at least one QTY+SCC+DTM in the SG12 loop per line — that's the elementary demand unit of a delivery schedule.

Real-world example

A weekly schedule sent by an OEM to its tier-1 supplier for two SKUs: a three-bucket firm release across June for the first, a single bucket for the second.

edifact delfor-d96a-example.edi
UNB+UNOC:3+5410000000123:14+5410000000456:14+260513:1430+CTRL000010'
UNH+1+DELFOR:D:96A:UN:EAN008'
BGM+241+DELFOR-2026-W20+9'
DTM+137:20260513:102'
DTM+157:20260601:102'
DTM+158:20260831:102'
NAD+BY+5410000000123::9'
NAD+SU+5410000000456::9'
UNS+D'
NAD+CN+5410000000789::9'
LIN+1++3520000001234:EN'
QTY+1:500'
SCC+1'
DTM+2:20260602:102'
QTY+1:500'
SCC+1'
DTM+2:20260616:102'
QTY+1:500'
SCC+1'
DTM+2:20260630:102'
LIN+2++3520000005678:EN'
QTY+1:2000'
SCC+1'
DTM+2:20260601:102'
UNS+S'
CNT+2:2'
UNT+25+1'
UNZ+1+CTRL000010'
  • BGM+241+DELFOR-2026-W20+9 — type 241 (Delivery schedule), number DELFOR-2026-W20, status 9 (Original).
  • DTM+137 — document date. DTM+157 / DTM+158 — start and end of the covered horizon.
  • NAD+BY / NAD+SU — Buyer and Supplier in the header.
  • UNS+D — switch into Detail.
  • NAD+CN — Consignee (delivery point) at Detail level (SG4).
  • First line: three QTY+1 (500 units) with SCC+1 (firm) and DTM+2 (requested delivery date) — the staggered release.
  • Second line: a single bucket for 2,000 units.
  • UNS+S + CNT+2:2 — Summary: 2 lines.
  • UNT+25+1 — 25 segments, reference "1" matching UNH.

Common errors

  • Missing or swapped UNS — DELFOR has two UNS segments (a UNS+D and a UNS+S), unlike ORDERS which only has one. Naive generators often forget UNS+D, which breaks the Header/Detail boundary.
  • SCC dropped from QTY — without SCC (Scheduling Conditions), the supplier cannot tell whether a quantity is firm, forecast, or indicative. Every serious automotive ERP requires SCC on each QTY+SCC+DTM tuple.
  • DELFOR vs DELJIT confusion — DELFOR covers the weekly horizon and beyond; for precise sequenced shipments at hourly/minute granularity (24h JIT), use DELJIT D.96A, which carries a dedicated SEQ segment.
  • QTY+1 vs QTY+21 — DELFOR uses QTY+1 (discrete quantity) for scheduled amounts, not QTY+21 (ordered quantity), which is specific to ORDERS.
  • Date formatDTM+2 expects a value matching the qualifier in component 3 (102 = CCYYMMDD). An ISO date will be rejected.

DELFOR sits in a blanket-contract + call-off flow:

  • ORDERS D.96A — the initial firm order or the blanket contract, referenced via RFF+CT.
  • DELJIT D.96A — the finer-grained JIT call (hourly sequence) that complements DELFOR.
  • DESADV D.96A — the despatch advice sent in response to each call-off.
  • RECADV D.96A — the buyer-side receipt advice.
  • INVRPT D.96A — the inventory report the supplier may send in parallel.
  • CONTRL D.96A — the automatic syntactic acknowledgment.

JSON equivalent

JSON projection matching the example above. The mapping is not normative — it's an ediverse convention to ease integration in TypeScript / Python environments.

json delfor-d96a-equivalent.json
{
  "interchange": {
    "controlRef": "CTRL000010",
    "from": { "id": "5410000000123", "qualifier": "14" },
    "to": { "id": "5410000000456", "qualifier": "14" },
    "datetime": "2026-05-13T14:30:00Z",
    "syntax": { "id": "UNOC", "version": "3" }
  },
  "message": {
    "ref": "1",
    "type": "DELFOR",
    "version": { "syntax": "D", "release": "96A", "agency": "UN", "association": "EAN008" }
  },
  "deliverySchedule": {
    "number": "DELFOR-2026-W20",
    "function": "241",
    "status": "9",
    "issueDate": "2026-05-13",
    "horizon": { "start": "2026-06-01", "end": "2026-08-31" },
    "parties": {
      "buyer": { "gln": "5410000000123" },
      "supplier": { "gln": "5410000000456" },
      "consignee": { "gln": "5410000000789" }
    },
    "lines": [
      {
        "ref": 1,
        "gtin": "3520000001234",
        "schedule": [
          { "quantity": 500, "deliveryDate": "2026-06-02" },
          { "quantity": 500, "deliveryDate": "2026-06-16" },
          { "quantity": 500, "deliveryDate": "2026-06-30" }
        ]
      },
      {
        "ref": 2,
        "gtin": "3520000005678",
        "schedule": [{ "quantity": 2000, "deliveryDate": "2026-06-01" }]
      }
    ],
    "totals": { "lineCount": 2 }
  }
}