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.

cXML ConfirmationRequest

Business-level order acknowledgment. Returned by the supplier in response to an OrderRequest; it tells the buyer, line by line, whether the order is accepted, changed, backordered, rejected, or pending. Functional equivalent of an EDIFACT ORDRSP.

Purpose

ConfirmationRequest exists because the supplier's accept/reject decision is not instantaneous — there is stock check, price check, credit check, etc. An HTTP 200 to OrderRequest only means "I received the document"; the business agreement comes through this transaction.

The type attribute on ConfirmationHeader is #REQUIRED and accepts eight values: accept (whole order OK), allDetail, detail (line-by-line changes), backordered (whole order on backorder), except (accepted with exceptions), reject (full rejection), requestToPay, replace.

XML structure

The DTD: ConfirmationRequest (ConfirmationHeader, OrderReference, (OrderStatusRequestReference | OrderStatusRequestIDInfo)*, ConfirmationItem*). The OrderReference is mandatory and carries a DocumentReference that points to the payloadID of the original OrderRequest.

ConfirmationHeader

Content: ConfirmationHeader (DocumentReference?, Total?, Shipping?, Tax?, Contact*, Hazard*, Comments*, IdReference*, Extrinsic*). No element is required by content; the minimum is the type and noticeDate attributes (noticeDate is declared #REQUIRED).

ConfirmationItem

Content: ConfirmationItem (UnitOfMeasure, Contact*, Hazard*, ConfirmationStatus+). So one mandatory unit of measure and at least one ConfirmationStatus. Attributes quantity and lineNumber are #REQUIRED.

ConfirmationStatus

Content: ConfirmationStatus (UnitOfMeasure, (ItemIn | (UnitPrice?, Tax?, Shipping?)), SupplierBatchID?, ScheduleLineReference?, ComponentConsumptionDetails*, Comments*, Extrinsic*). Attributes quantity and type are #REQUIRED. The type takes seven values: accept, allDetail, detail, backordered, reject, unknown, requestToPay. The sum of quantity across all ConfirmationStatus inside a given ConfirmationItem must equal the quantity of that ConfirmationItem — explicitly stated in the DTD.

xml confirmation-request.cxml.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.069/cXML.dtd">
<cXML payloadID="260513.180000.conf@supplier.example"
      timestamp="2026-05-13T18:00:00+00:00"
      version="1.2.069">
  <Header>
    <From>
      <Credential domain="DUNS"><Identity>987654321</Identity></Credential>
    </From>
    <To>
      <Credential domain="DUNS"><Identity>123456789</Identity></Credential>
    </To>
    <Sender>
      <Credential domain="DUNS">
        <Identity>987654321</Identity>
        <SharedSecret>shared-secret-here</SharedSecret>
      </Credential>
      <UserAgent>supplier-erp/2.1</UserAgent>
    </Sender>
  </Header>
  <Request>
    <ConfirmationRequest>
      <ConfirmationHeader confirmID="CONF-2026-00123"
                          operation="new"
                          type="detail"
                          noticeDate="2026-05-13T18:00:00+00:00">
        <Total>
          <Money currency="USD">129.97</Money>
        </Total>
        <Comments xml:lang="en">Line 1 ships in 3 days, line 2 is backordered.</Comments>
      </ConfirmationHeader>
      <OrderReference orderID="PO-2026-00789"
                      orderDate="2026-05-13T16:00:00+00:00">
        <DocumentReference payloadID="260513.160000.order@buyer.example"/>
      </OrderReference>
      <ConfirmationItem quantity="3" lineNumber="1">
        <UnitOfMeasure>EA</UnitOfMeasure>
        <ConfirmationStatus quantity="3"
                            type="detail"
                            shipmentDate="2026-05-16T08:00:00+00:00"
                            deliveryDate="2026-05-18T10:00:00+00:00">
          <UnitOfMeasure>EA</UnitOfMeasure>
          <UnitPrice><Money currency="USD">29.99</Money></UnitPrice>
        </ConfirmationStatus>
      </ConfirmationItem>
      <ConfirmationItem quantity="2" lineNumber="2">
        <UnitOfMeasure>EA</UnitOfMeasure>
        <ConfirmationStatus quantity="2" type="backordered">
          <UnitOfMeasure>EA</UnitOfMeasure>
        </ConfirmationStatus>
      </ConfirmationItem>
    </ConfirmationRequest>
  </Request>
</cXML>

Required vs optional

  • ConfirmationHeader attributes: type and noticeDate are #REQUIRED; confirmID, operation, invoiceID, incoTerms, version are #IMPLIED.
  • OrderReference: cardinality 1 (required); contains a required DocumentReference with a payloadID.
  • ConfirmationItem: repeats 0..n. For a type="reject" header, the DTD forbids items.
  • ConfirmationStatus: at least one per ConfirmationItem. quantity and type are #REQUIRED.

Common patterns

Split confirmation: a single ConfirmationItem may carry several ConfirmationStatus entries of different types — e.g. "2 units accepted, 3 units backordered" for a 5-unit line. The sum rule guarantees no quantity is lost.

Update an acknowledgment: reuse the same confirmID with operation="update". The DTD then requires a DocumentReference pointing to the previous confirmation. A new version replaces the previous one entirely.

For scheduling-agreement orders: use ScheduleLineReference inside ConfirmationStatus to point at a specific schedule line.

Documentation