Overview
The INVOIC message is one of the most widely implemented EDIFACT message types in electronic data interchange. It is used by a supplier (seller) to send an invoice to a buyer, detailing the goods or services provided, the amounts owed, applicable taxes, payment terms, and references to related commercial documents such as purchase orders and despatch advices.
Beyond standard commercial invoices, the INVOIC message type also supports credit notes, debit notes, corrective invoices, pro-forma invoices, and self-billing invoices. The specific function is identified in the BGM (Beginning of Message) segment using a document name code — for example, code 380 represents a standard commercial invoice, while 381 represents a credit note.
The INVOIC message plays a central role in automating accounts payable processes. When integrated into an ERP system, incoming INVOIC messages can be matched against purchase orders (ORDERS) and goods receipts (RECADV) through a three-way matching process, enabling straight-through processing without manual intervention.
Message Structure
An INVOIC message is organized into a header section, a detail section containing line items, and a summary section. The header carries information that applies to the entire invoice — such as parties, dates, payment terms, and currency. The detail section repeats for each invoiced item, carrying product identification, quantities, prices, and line-level taxes. The summary section provides totals and overall tax calculations.
Key Segments
| Segment | Name | Purpose |
|---|---|---|
UNH | Message Header | Identifies the message type (INVOIC) and directory version |
BGM | Beginning of Message | Specifies the invoice number and document function (original, replacement, credit note) |
DTM | Date/Time/Period | Invoice date, tax point date, delivery date, payment due date |
RFF | Reference | Links to purchase order number, despatch advice number, contract number |
NAD | Name and Address | Identifies buyer (BY), supplier (SU), invoicee (IV), and delivery party (DP) |
CUX | Currencies | Defines the invoice currency and any exchange rate information |
PAT | Payment Terms | Specifies payment conditions, discount terms, and due dates |
LIN | Line Item | Identifies each invoiced product by GTIN, buyer article number, or supplier code |
QTY | Quantity | Invoiced quantity, delivered quantity, returned quantity |
MOA | Monetary Amount | Line item amount, total invoice amount, tax amounts, allowance/charge amounts |
PRI | Price Details | Unit price (net or gross) with price qualifier |
TAX | Duty/Tax/Fee | VAT rate, tax category, and tax amounts at header and line level |
ALC | Allowance or Charge | Discounts, surcharges, freight charges, and other adjustments |
UNS | Section Control | Separates the detail section from the summary section |
UNT | Message Trailer | Provides segment count and message reference number for integrity checking |
Common Use Cases
- Retail invoicing: Suppliers send INVOIC messages to retail chains after goods have been delivered, referencing the original ORDERS and DESADV. The retailer's system performs three-way matching (order, receipt, invoice) before approving payment.
- Self-billing: In some industries, the buyer generates the invoice on behalf of the supplier (evaluated receipts settlement). The INVOIC message with the appropriate function code is sent from buyer to supplier.
- Credit notes: When goods are returned or pricing adjustments are needed, a credit note INVOIC (BGM code 381) references the original invoice and specifies the credit amounts.
- Consolidated invoicing: A single INVOIC message can cover multiple deliveries or purchase orders by including multiple RFF references and corresponding line items.
- Cross-border trade: International invoices include additional data such as customs tariff numbers, country of origin, and Incoterms codes within the INVOIC structure.
Example Snippet
The following shows a simplified INVOIC message fragment illustrating the basic structure:
UNH+1+INVOIC:D:96A:UN:EAN008'
BGM+380+INV-2024-00123+9'
DTM+137:20240315:102'
RFF+ON:PO-2024-00456'
NAD+BY+5412345000013::9'
NAD+SU+4012345000010::9'
CUX+2:EUR:4'
LIN+1++4012345000027:SRV'
QTY+47:100:PCE'
PRI+AAA:25.50'
TAX+7+VAT+++:::19'
MOA+203:2550.00'
UNS+S'
MOA+86:3034.50'
MOA+176:484.50'
TAX+7+VAT+++:::19'
MOA+124:484.50'
UNT+16+1'Implementation Considerations
When implementing INVOIC, ensure your mapping handles the different document function codes in BGM — a single interface must typically process invoices, credit notes, and debit notes. Tax handling is particularly important: the TAX segment can appear at both header level (applying to the entire invoice) and line level (applying to individual items), and your logic must correctly aggregate tax amounts in the summary section.
Allowances and charges (ALC segments) add complexity because they can appear at the header level, the line item level, or both. Header-level allowances apply proportionally across all line items, while line-level allowances apply only to that specific item. Your calculation logic must account for both to match the supplier's totals.
For EANCOM implementations (retail/FMCG), party identification typically uses GLN (Global Location Numbers) in the NAD segment, and products are identified by GTIN in the LIN segment. Other industry guidelines may use different identification schemes.
Related Message Types
- ORDERS — The purchase order that the invoice references
- DESADV — The despatch advice confirming shipment of invoiced goods
- RECADV — The receiving advice confirming receipt, used in three-way matching
- REMADV — The remittance advice sent with payment referencing this invoice
- CONTRL — Syntax acknowledgment of the received invoice interchange