What is the EDIFACT INVRPT Message?
The
EDIFACT INVRPT (Inventory Report) is an electronic document used in global supply chains to communicate inventory levels and product stock status between trading partners and carries data related to current stock, available stock, embargoed, reserved or damaged quantities, storage locations, ownership, consignment, in-transit balances, and hierarchical packing with unique identification such as GTINs, and SSCCs when available.
The EDIFACT INVRPT (Inventory Report) provides detailed structured data such as:
- Current stock on hand
- Stock available vs. reserved or damaged
- Stock by location, warehouse, pallet, or batch number
- Consignment, VMI (Vendor Managed Inventory), or owned inventory
- Future or in-transit stock quantities
- Packing hierarchies and SSCC-level identifiers
An UN/EDIFACT standard, the EDIFACT INVRPT (Inventory Report) transaction message is commonly exchanged between manufacturers, retailers, distributors, third-party logistics providers (3PLs), Logistics Service Providers.
How is the EDIFACT INVRPT Message Used?
Organizations 
generate INVRPT messages automatically by request or on a schedule, or in response to inventory events such as moves, transfers, shipments, and OSD discoveries. Common applications include VMI, warehouse stock reporting, retail replenishment, and consignment tracking.
How does PartnerLinQ use the EDIFACT INVRPT Message?
PartnerLinQ supports event-driven and extended cycle-based INVRPT messages as part of its Digital Connectivity and Smart Visibility framework, enabling manufacturers, retailers, distributors, third-party logistics providers (3PLs), and Logistics Service Providers (LSPs) to maintain real-time visibility into inventory across global trading networks.
Integrations can trigger automated data retrievals, generate scheduled requests, responses, and report messages, ingest, transform, convert, or append WMS/ERP data in hundreds of the most recognized systems by name, names such as SAP, D365, JDA, or Manhattan, into EDIFACT INVRPT messages for trading partners
PartnerLinQ dashboards can show whether an INVRPT message is overdue or missing and raise alerts and automatically respond if a partner wants to request, respond to, or report inventory data via EDIFACT INVRPT Messages.
How do larger dairy and food products companies use the EDIFACT INVRPT Message?
Global 
dairy and food manufacturers rely on EDIFACT INVRPT to report inventory levels and product stock status. Third-party logistics providers (3PLs), Logistics Service Providers (LSPs)such as DSV, DHL, and GXO, send stock-level INVRPT feeds to manufacturers, retailers, and distributors, who maintain this data in their ERP, MES, and WMS systems like SAP ECC or S4 HANA, EWM, D365, Oracle, and Manhattan. They send status segments such as STS and inventory details in INV to support quarantine, expiry, regulated traceability, shelf-life, and quality controls, including damage tracking (OSD).
What does the INVRPT support? (Key Features)
The EDIFACT INVRPT (Inventory Report) transaction message supports network-wide stock visibility, qualified quantities, ownership and movement context, batch/serial capture, expiry tracking, location granularity, hierarchical packaging, and exception signaling via statuses and references. PartnerLinQ enables automation and alerting.
What is the Purpose of the EDIFACT INVRPT Message?
The 
EDIFACT INVRPT message provides a standardized, authoritative view of inventory balances to drive replenishment, planning, financial reconciliation, and compliance across heterogeneous systems.
What Information is Included in the INVRPT?
The EDIFACT INVRPT (Inventory Report) message includes headers and service control, party and item identification, unique product codes (EANs, GTINs), qualified unit level inventory quantities in an Inventory Management context, unit traceability identification such as serial, lot, batch, location and timing, reference and reference data such as packaging hierarchy, and lastly the EDIFACT INVRPT (Inventory Report) transaction message includes a control trailer.
What are the Essential Components of the EDIFACT INVRPT message?
While not always mandatory, essential components of the EDIFACT INVRPT message include service segments and message headers, party details, item and quantity groups, inventory context, identity numbers, locations, statuses, references, and packaging. Essential Component use cases reflect typical warehouse and terminal handling processes documented in PartnerLinQ guidance, reflect D.96A usage, and include larger dairy and food product company use cases.
| Segment | Essential Notes |
|---|---|
| UNH – Message Header | Identifies INVRPT and assigns a message reference; mandatory once. |
| BGM – Beginning of Message | Defines type, number, and function (e.g., Original); mandatory. |
| DTM – Date/Time/Period | Specifies issue date/time and periods using ISO 8601; mandatory up to 10. |
| NAD – Name and Address | Specifies parties such as Goods Owner (GO), Inventory Reporting Party (GY), Warehouse (WH); mandatory in SG2. |
| LIN – Line Item | Identifies the line item; foundation for detail; mandatory in SG9. |
| PIA – Additional Product ID | Provides alternate identifiers such as supplier article; conditional. |
| QTY – Quantity | Provides qualified quantities (e.g., actual stock) with units; mandatory in SG11. |
| INV – Inventory Related Details | Adds movement direction and inventory management parameters; conditional. |
| GIN – Goods Identity Number | Provides batch, serial, or SSCC identifiers; conditional. |
| LOC – Place/Location Identification | Indicates warehouse, zone, or bin; conditional. |
| STS – Status | Conveys condition such as damaged or quarantine to affect availability; conditional. |
| RFF – Reference | References documents and numbers tied to quantities. |
| CPS – Consignment Packing Sequence | Defines hierarchical packing; mandatory in SG15. |
| PAC – Package | Specifies the number and type of packages. |
| UNT – Message Trailer | Provides segment count and control reference; mandatory once. |
What are the Common Segments Included in the EDIFACT INVRPT?
Common header segments include UNH, BGM, DTM, and NAD. Common detail segments include LIN, PIA, QTY, INV, GIN, LOC, STS, RFF, CPS, and PAC. The message ends with UNT.
Common Segment use cases reflect typical warehouse and terminal handling processes documented in PartnerLinQ guidance, reflect D.96A usage, and include larger dairy and food products use cases.
| Tag | Level | Purpose | Usage | Rep |
|---|---|---|---|---|
| UNH | Header | Identify message as INVRPT; set reference | Mandatory | Once |
| BGM | Header | Document number and function | Mandatory | Once |
| DTM | Header | Document date/time | Mandatory | 1..10 |
| NAD | Header | Parties (GO, GY, WH, PO) | Mandatory in SG2 | Per party |
| LIN | Detail | Line item identifier | Mandatory in SG9 | Per item |
| PIA | Detail | Alternate item IDs | Conditional | 0..10 |
| QTY | Detail | Qualified quantities | Mandatory in SG11 | Per item |
| INV | Detail | Inventory management details | Conditional | Per item |
| GIN | Detail | Batch/serial/SSCC | Conditional | As needed |
| LOC | Detail | Location/bin | Conditional | 0..5 |
| STS | Detail | Status/condition | Conditional | 0..9 |
| RFF | Detail | References | Mandatory in SG14 | Per quantity |
| CPS | Detail | Packing sequence | Mandatory in SG15 | Per hierarchy |
| PAC | Detail | Package count/type | Mandatory in SG16 | Per hierarchy |
| UNT | Trailer | Segment count and control | Mandatory | Once |
What Status Codes are used with the EDIFACT INVRPT?
The
EDIFACT INVRPT does provide status for codes in the STS – Status segment, which provides status information about goods, inventory conditions, processing progress, or stock availability. The STS segment adds dynamic state information about the inventory being reported—beyond the basic quantity, product code, or location and helps to communicate whether inventory is available, damaged, quarantined, in transit, reserved, obsolete, expired, is undergoing inspection, in production processing, or is totally missing, codes that inform availability decisions and trigger quality actions.
What Reason Codes are used with the EDIFACT INVRPT?
The EDIFACT INVRPT does provide for reason codes that qualify statuses and adjustments, explain discrepancies, and temporary ‘holds’ for various reasons (e.g., Dock Strikes, Import Restrictions, mechanical Breakdown). While larger dairy and food products companies generally do not publicly document specific messages, their implementation guidelines typically define reason codes.
What Use Cases does the EDIFACT INVRPT (Inventory Report) transaction message support?
Typical EDIFACT INVRPT use cases reflect warehouse and terminal handling processes documented in PartnerLinQ guidance; they reflect D.96A usage and include larger dairy and food products use cases.
| Use Case | Description |
|---|---|
| Production & Raw Materials | Plants report stock to planning systems for procurement alignment. |
| 3PL/Warehouse Reporting | Logistics providers report balances to brand owners or manufacturers. |
| Retail Replenishment | Retailers send daily or weekly stock by SKU to suppliers. |
| Consignment Inventory | Stock at customer sites but owned by suppliers is tracked. |
| Vendor Managed Inventory | Suppliers replenish based on buyer or 3PL inventory feeds. |
| Expiry-Sensitive Goods | Pharma and dairy rely on batch/expiry visibility and statuses. |
What are the Benefits of the EDIFACT INVRPT message?
Manufacturers, retailers, distributors, third-party logistics providers (3PLs), and Logistics Service Providers (LSPs) organizations gain shared visibility with the EDIFACT INVRPT message, faster replenishment, reduced shrinkage and write-offs, stronger recall readiness, and consistent reporting across networks.
How efficient is the EDIFACT INVRPT message?
Whether cycle-based or event-driven, EDIFACT INVRPT message automation reduces manual reconciliation and accelerates decision-making. Dashboarding can show whether an INVRPT message is overdue or missing, can flag missing or late reports, and send alerts.
How Compliant is the EDIFACT INVRPT message?
The structure and function of the EDIFACT INVRPT message support audits and regulatory obligations, while service segments and CONTRL acknowledgments provide interchange control.
What is the Format of the EDIFACT INVRPT message?
The EDIFACT INVRPT message conforms to UN/EDIFACT D.96A, with service segments including UNB/UNZ and UNH/UNT. PartnerLinQ uses UNA:+.?' and CONTRL for syntactical control and acknowledgments, and generates CONTRL functional acknowledgments.
How Accurate is the INVRPT?
Accuracy relies on correct qualifiers and units in QTY, precise locations in LOC, and identity capture in GIN. ISO 8601 guidance and GS1 AI time stamps improve temporal precision. The sender’s ability to provide clear and concise instructions also has an impact on accuracy. Making the EDIFACT INVRPT message possible includes the ability to capture and control reliable identities such as SSCC, precise locations, correct party and item identifiers, and handling qualifiers.
What are the Limitations of the INVRPT?
EDIFACT does not publish a separate INVRPT Request message. Implementers rely on schedules, triggers, or APIs to solicit current balances. Local code lists require governance to avoid ambiguity.
Are Guidelines & Sample Files for the EDIFACT INVRPT (Inventory Report) transaction message available?
Yes. PartnerLinQ provides sample EDIFACT INVRPT Transaction and implementation guides are available through its Support and Guideline Management Team.
Sample EDIFACT INVRPT implementation guides illustrate both inbound and outbound flows, segment layouts, and valid data examples and support testing and partner onboarding. Customized specification documents for use in on boarding and technical development are available upon request.
PartnerLinQ provides:
- EDIFACT INVRPT transaction implementation guide
- Sample payloads
- Qualification and testing maps
- Error handling and best-practice notes
What are the Basic Questions for EDI Integration with the EDIFACT INVRPT?
Use cases reflect typical warehouse and terminal handling processes documented in PartnerLinQ guidance and executed with the EDIFACT INVRPT (Inventory Report) transaction message
- What EDI version and standard will be used?
- What is the general direction of the transaction?
- Are they Inbound from or outbound to another party?
- Which acknowledgments (MDN/CONTRL) are required?
- What response is expected or sent in response to the transaction?
- Are there samples and specs of the response transaction available?
- Are there other parties interested in the EDIFACT INVRPT Message?
- What transactions might these interested parties be a party to?
- Are there distinct types of EDIFACT INVRPT message (e.g., request, response, and report) that need to be tracked or handled differently?
- Are there any business rules that should be considered when processing an EDIFACT INVRPT request message? (e.g., invalid/missing item or customer identification number)
- Are Batch or Lot numbers a consideration for Inventory Tracking?
- Is there product serialization?
- Are returns validated?
- How are changes/cancellations/rejections to the EDIFACT INVRPT business message managed today?
- Is there automation? (internal systems triggers) Or are EDIFACT INVRPT messages triggered manually?
- Are response messages (e.g., request, response, and report) automatically triggered? (an internal systems trigger) Or do transactions require human intervention/approval?
- Which locations and status codes will be reported?
- Which identifiers (EAN, supplier article, batch, SSCC) will be exchanged?
- Which schedules or events will trigger EDIFACT INVRPT generation?
- Which acknowledgments (CONTRL, MDN) will be required?
- Which references and document numbers must be echoed?
What Business Level Workflow does the INVRPT support?
The typical workflow begins with a scheduled or a triggered event (e.g., request, response and report automation), and proceeds through extraction from WMS/ERP, maps to D.96A segments, transmits over AS2, generates CONTRL, and updates dashboards for exceptions execution, reconciliation, and replenishment decisions.
What are the Best Practices for using the INVRPT?
Best Practices reflect PartnerLinQ implementation guidance for handling operations.
| Practice | Recommendation |
|---|---|
| Use precise qualifiers | Apply DTM formats and QTY qualifiers consistently. |
| Capture identity numbers | Provide serial, batch, and SSCC when relevant. |
| Convey status clearly | Use STS with reason codes to enable action. |
| Model hierarchy | Use CPS and PAC to reflect packing levels correctly. |
| Align code lists | Document local codes and responsibilities. |
| Automate control | Enable CONTRL and dashboard alerts for timeliness. |
What Transactions are associated with the INVRPT?
Associations vary by party and flow; CONTRL and MDN support exchange integrity.
| Transaction | Role |
|---|---|
| CONTRL | EDIFACT functional acknowledgment for syntax/receipt. |
| ORDERS / ORDRSP | Ordering context and responses are used with replenishment flows (VMI). |
| DESADV | Shipment notices that adjust on-hand balances. |
| INVOIC | Billing is tied to inventory movements where applicable. |
| INVRPT (Request) | While not widely used, an INVRPT can be configured as a request. |
Footnotes
1. PartnerLinQ INVRP EDIFACT vD96A 20251022 (PDF).
2. EDIFACT INVRPT Notes 20251023 (DOCX).
Explore Our Integration Solutions
PartnerLinQ Integration Solutions
Connect Everything. Integrate Intelligently.
Future-Proof Your Business with Composable, AI Powered Connectivity.