What Is EDI 855? Purchase Order Acknowledgment Statuses, Changes, and Exceptions

If you’re new to EDI 855 and its applications, this guide will help you understand its basics.

1. Why EDI 855 Matters Before an Order Reaches the Warehouse

EDI 855 gives a buyer a structured response to a purchase order after the supplier reviews it. Therefore, the document does much more than confirm that an electronic file arrived. Instead, it can communicate whether the supplier accepts the order, rejects it, or needs to change important details.

For example, a supplier may accept one line exactly as ordered while reducing another quantity because inventory has changed. Meanwhile, another line may require a later delivery date. As a result, the buyer needs more than a simple “received” message.

Moreover, these differences affect inventory planning, receiving, purchasing, fulfillment, and accounting. Consequently, businesses that process high volumes of wholesale or retail orders need the acknowledgment to match operational reality.

1.1 What Is EDI 855?

X12 defines EDI 855 as the Purchase Order Acknowledgment transaction set. In a typical workflow, a seller uses it to respond to a buyer’s purchase order.

Therefore, the 855 represents a business response. It can communicate acceptance, rejection, or detailed changes when the applicable implementation supports them.

For an authoritative definition, X12 maintains the official X12 transaction set directory.

1.2 Who Sends and Receives an EDI 855?

Typically, the buyer sends an EDI 850 Purchase Order to a supplier. Next, the supplier processes that order and sends the acknowledgment back.

Therefore, the common direction looks like this:

Buyer → EDI 850 → Supplier → EDI 855 → Buyer

However, businesses should still check the trading-partner agreement. Although this flow is common, each relationship can define additional requirements.

2. How EDI 855 Fits Into the Purchase Order Lifecycle

The 855 sits between receiving an order and executing that order. Therefore, it creates an important checkpoint before warehouse and shipping activity begins.

Moreover, this checkpoint allows both parties to resolve differences early. As a result, the buyer can update expectations before receiving an ASN or invoice that conflicts with the original PO.

2.1 EDI 850 Starts the Order

First, the buyer sends an EDI 850 Purchase Order. That document can contain items, quantities, prices, locations, dates, and other agreed purchasing data.

Next, the supplier imports or processes that information. However, the supplier still needs to determine whether it can fulfill every requirement.

Therefore, receiving an 850 does not automatically mean the supplier accepts every line exactly as submitted.

2.2 EDI 855 Communicates the Supplier’s Response

After validating the order, the supplier can generate an 855.

For example, the supplier may confirm all quantities. Alternatively, it may reduce a quantity, propose another date, communicate a pricing difference, substitute a product where permitted, or reject a line.

Consequently, the buyer receives a structured explanation of what the supplier actually plans to fulfill.

2.3 EDI 856 and 810 Follow Later Events

After the parties resolve the order commitment, fulfillment continues. Then, an EDI 856 can communicate shipment details. Finally, an EDI 810 can communicate invoice information.

Therefore, a simplified sequence looks like this:

EDI 850 Purchase Order → EDI 855 Acknowledgment → EDI 856 ASN → EDI 810 Invoice

However, the exact document flow depends on each trading relationship.

3. What Information Can an EDI 855 Communicate?

An 855 can carry both order-level and line-level information. Therefore, teams should not treat every acknowledgment as a single yes-or-no answer.

Instead, a detailed acknowledgment can show exactly where the supplier’s response differs from the original order.

3.1 Header-Level Information

At the header level, the transaction can identify the purchase order and the overall acknowledgment context.

For example, the message may include:

• purchase order number;
• purchase order date;
• acknowledgment type;
• acknowledgment date;
• supplier references;
• agreed business identifiers.

Therefore, the receiving system can connect the acknowledgment to the correct customer order.

3.2 Line-Level Information

At the line level, the supplier can communicate more detailed outcomes.

For example, line-level data can identify:

• the original PO line;
• item references;
• quantity response;
• unit of measure;
• status;
• relevant dates;
• pricing information;
• substitution information.

Consequently, buyers can react to individual exceptions without treating the entire purchase order as one outcome.

4. The Main EDI 855 Segments to Understand

An 855 contains several segments that organize the response. However, implementation details depend on the X12 version and trading-partner guide.

Therefore, teams should understand each segment’s business role before they begin mapping.

4.1 ST — Transaction Set Header

The ST segment starts the transaction set and identifies the document as an 855.

Therefore, receiving systems use it as part of transaction control and document identification.

4.2 BAK — Beginning Segment

The BAK segment establishes the overall purchase order acknowledgment context.

For example, documented X12 855 examples use BAK to communicate the acknowledgment type and reference the original purchase order.

Consequently, BAK helps the buyer understand the supplier’s overall response before reviewing individual lines.

4.3 PO1 — Purchase Order Line Detail

The PO1 segment can carry the relevant line-item information.

Therefore, a detailed acknowledgment can connect the supplier’s response to a specific original order line instead of forcing users to interpret an order-level status alone.

4.4 ACK — Line Item Acknowledgment

The ACK segment carries line-level acknowledgment information.

For example, X12’s 855 accepted-with-changes example shows ACK communicating line status and certain changes.

Therefore, ACK often becomes one of the most important segments for exception handling.

4.5 CTP, CTT, and SE

CTP can communicate pricing information when the implementation requires it. Meanwhile, CTT can communicate transaction totals. Finally, SE closes the transaction set.

However, businesses should never build a production map solely from a generic example. Instead, they should follow the actual partner specification.

5. EDI 855 Acknowledgment Statuses Explained

Status information tells the buyer how the supplier responded. However, teams should separate header acknowledgment types from line-level status information.

That distinction matters because a purchase order may contain several different line outcomes.

5.1 Common Header-Level Patterns

X12’s published 004010X358 examples demonstrate several acknowledgment patterns:

Response	Example X12 code	Business meaning
Accepted without detail	AT	Supplier accepts the order without returning detailed lines
Accepted with detail	AD	Supplier provides detailed acknowledgment information
Accepted with changes	AC	Supplier returns detail and communicates changes
Rejected	RJ	Supplier rejects the purchase order

Therefore, these examples help teams understand the basic response patterns.

However, they do not mean every trading partner accepts every code. Instead, the implementation guide controls what the connection permits.

5.2 Why the Overall Status Is Not Enough

Suppose a PO contains 40 lines. Although 38 lines may match perfectly, one line may have insufficient inventory while another has a date issue.

Therefore, an overall “accepted with changes” status tells only part of the story.

Instead, operations teams need line-level detail so they can determine which products, quantities, and dates require action.

6. EDI 855 Line-Level Status Codes and Their Meaning

Line-level statuses turn the acknowledgment into actionable operational data. Therefore, the buyer can determine which exact PO lines need review.

X12’s 004010X358 change example demonstrates several useful status concepts.

Business outcome	Example code	Operational meaning
Item accepted	IA	Supplier accepts the line
Item rejected	IR	Supplier rejects the line
Quantity changed	IQ	Supplier proposes a different quantity
Price changed	IP	Supplier communicates a price difference
Date rescheduled	DR	Supplier proposes another date
Item substituted	IS	Supplier proposes another product

However, teams should treat these as documented X12 example codes, not as a universal retailer codebook.

6.1 Quantity Statuses Need Operational Context

For example, a supplier may receive an order for 500 units but have only 420 available for the requested period.

Therefore, the acknowledgment should reflect the quantity the supplier can actually commit under the agreed rules.

As a result, the buyer can update purchasing, allocation, replenishment, and downstream expectations before shipment.

6.2 Rejections Need Clear Follow-Up

Similarly, a rejected line should trigger a defined business response.

For example, customer service may need to confirm a substitute. Alternatively, the buyer may cancel the line or issue an order change.

Therefore, the EDI code should initiate a workflow rather than simply remain inside an EDI log.

7. How EDI 855 Handles Quantity Changes

Quantity differences create some of the most common order exceptions. Therefore, suppliers need a consistent rule for deciding how much inventory they can safely acknowledge.

For example, assume a buyer orders 1,000 units. However, the supplier can commit only 700 before the requested date.

The supplier should not acknowledge all 1,000 simply because the 850 requested them. Instead, the acknowledgment should reflect the agreed business response.

7.1 Available Inventory Should Drive the Decision

First, the system should determine which stock can actually support the order.

However, “quantity on hand” alone may not provide the right answer. Existing allocations, holds, safety stock, open transfers, production demand, and warehouse availability can all change what the supplier can promise.

Therefore, the acknowledgment process needs access to reliable available inventory.

7.2 Partial Availability Needs a Defined Rule

Next, the supplier must decide what happens when it cannot fill the full quantity.

For example, the business may:

• acknowledge a reduced quantity;
• backorder the balance;
• reject the line;
• move the requested date;
• route the exception for review.

Consequently, automation works best when teams define these rules before volume increases.

8. How EDI 855 Handles Price and Date Changes

Quantity is only one source of mismatch. In addition, the supplier may disagree with the PO price or may not meet the requested date.

Therefore, the acknowledgment process should validate commercial and fulfillment data before it sends a response.

8.1 Price Changes

For example, a retailer may submit a price that no longer matches the supplier’s approved customer contract.

Therefore, the supplier should compare the PO against current pricing rules before committing the line.

Moreover, X12’s documented change example demonstrates a price-change scenario using acknowledgment and pricing information.

Consequently, finance and customer-service teams can address the variance before invoicing creates another mismatch.

8.2 Date Changes

Similarly, a requested date may no longer be achievable.

For example, inventory may arrive late from a supplier. Alternatively, production may require more time or the warehouse may face capacity constraints.

Therefore, the seller may need to communicate a revised date through the agreed implementation.

As a result, both parties can plan around the new commitment instead of discovering the delay during shipment.

9. Product Substitutions, Holds, and Backorders

Not every exception fits neatly into quantity, price, or date. Therefore, businesses also need rules for product substitutions, holds, discontinued SKUs, and backorders.

9.1 Product Substitutions

A supplier may propose an alternate item when the original SKU is unavailable and the relationship permits substitutions.

However, the replacement can affect merchandising, customer expectations, packaging, price, and inventory records.

Therefore, teams should not treat substitution as an invisible SKU swap. Instead, they should create an approval process where necessary.

9.2 Backorders and Holds

Similarly, a temporary shortage may not require a permanent rejection.

However, the correct representation depends on the partner’s implementation guide.

Therefore, suppliers should never assume that one generic status or code works for every customer. Instead, they should map each trading partner’s accepted workflow.

10. Trading-Partner Rules Matter More Than Generic Code Lists

X12 provides the transaction framework. However, each trading partner can narrow that framework through its implementation guide.

Consequently, two retailers may both require EDI 855 while enforcing different segments, codes, timing rules, or validation requirements.

10.1 Retailers Can Define Required Segments

For example, Walmart’s current 855 Purchase Order Acknowledgement guide identifies required segment usage for its implementation.

Therefore, a map that works for another retailer may fail Walmart validation.

10.2 Retailers Can Restrict Status Codes

Similarly, a trading partner may support only selected ACK01 values.

Therefore, developers should not send every code that the wider X12 standard can represent. Instead, they should configure the map for each partner.

10.3 Response Timing Can Also Differ

Moreover, buyers may establish different acknowledgment deadlines.

Therefore, businesses should store timing requirements by partner rather than hard-code one global SLA.

As a result, the EDI process becomes flexible without becoming inconsistent.

11. EDI 855 vs EDI 850, 856, 865, and 997

Teams often confuse EDI transactions because several documents relate to the same order. However, each document represents a different business event.

Transaction	Main purpose
EDI 850	Buyer places a purchase order
EDI 855	Supplier acknowledges the purchase order
EDI 856	Supplier communicates shipment information
EDI 865	Seller responds to or initiates PO changes
EDI 997	System communicates functional acknowledgment
EDI 810	Supplier sends invoice information

11.1 EDI 855 vs EDI 997

The distinction between 855 and 997 matters especially.

A 997 relates to the processing of an EDI transaction. However, it does not replace the seller’s business response to the purchase order.

Therefore, a successful technical acknowledgment does not necessarily mean the supplier accepted every item, quantity, price, or date.

11.2 EDI 855 vs EDI 856

Similarly, an 855 does not prove that the supplier shipped the order.

Instead, an 856 communicates shipment-related information.

Therefore, teams should keep order commitment and shipment execution as separate events.

12. How ERP Software Can Generate an EDI 855

As order volume grows, manual acknowledgment becomes difficult to control. Therefore, businesses often connect EDI processing to the ERP system that manages the underlying order data.

A typical workflow looks like this:

1. First, receive the EDI 850.
2. Next, identify the customer and ship-to location.
3. Then, map retailer item numbers to internal SKUs.
4. After that, validate units of measure.
5. Next, check inventory availability.
6. Then, validate customer pricing.
7. Meanwhile, calculate achievable fulfillment dates.
8. Finally, create the acknowledgment and send it through the EDI connection.

Consequently, the 855 can reflect the same data that operations uses to fulfill the order.

For businesses evaluating a unified operational platform, XoroONE connects inventory, orders, purchasing, warehouse processes, accounting, and related workflows within one ERP environment.

13. Why EDI Translation Alone Does Not Solve the Problem

An EDI translator can convert data from one format to another. However, translation alone cannot decide whether a business can fulfill 900 units, honor a price, or meet a requested date.

Therefore, the operational system still needs to make the business decision.

13.1 Inventory Must Match the Commitment

For example, the EDI layer may correctly translate “1,000 units.” However, the ERP may know that 400 units already belong to other orders.

Therefore, the system should resolve inventory availability before sending the acknowledgment.

13.2 Warehouse Reality Also Matters

Similarly, stock can exist physically while still being unavailable for immediate fulfillment.

For example, inventory may sit in another warehouse, quarantine location, or transfer.

Therefore, businesses that need real-time warehouse execution can connect EDI workflows with a system such as XoroWMS so order commitments and warehouse activity rely on aligned operational data.

14. How to Manage EDI 855 Exceptions Without Creating Manual Chaos

Automation should reduce repetitive work. However, it should not automatically approve every exception.

Instead, teams should define which conditions the system can resolve and which conditions need human review.

14.1 Automatically Process Low-Risk Outcomes

For example, the system may automatically acknowledge an unchanged order when inventory, price, customer, SKU, and date validations all pass.

Therefore, employees do not need to review routine transactions.

14.2 Route Material Exceptions

However, a large quantity reduction or major price difference may require approval.

Consequently, the system should send that exception to the right owner instead of burying it in an EDI log.

Businesses can use Xorosoft Integrations to connect operational workflows with external commerce and business systems while keeping core transaction data synchronized.

14.3 Preserve an Audit Trail

Finally, teams should preserve the original PO, acknowledgment, changes, approvals, and downstream order status.

Therefore, users can investigate disputes without reconstructing the history from email and spreadsheets.

15. Common EDI 855 Automation Mistakes

EDI automation can still produce bad commitments when the underlying rules or data are weak. Therefore, teams should focus on business accuracy, not only successful file transmission.

15.1 Sending the 855 Too Early

If the system generates an acknowledgment before inventory and pricing validation, it may promise something operations cannot deliver.

Therefore, validation should occur before the final business response.

15.2 Using Stale Inventory

Similarly, yesterday’s inventory snapshot may not reflect today’s allocations.

Consequently, growing businesses need an ERP such as XoroERP when order volume, inventory complexity, and multi-location execution require tighter operational control.

15.3 Ignoring Line-Level Differences

An overall acceptance status can hide important exceptions.

Therefore, teams should evaluate the line detail whenever the partner requires detailed acknowledgment.

15.4 Treating a Successful EDI Transfer as a Successful Order

A technically successful transmission proves only part of the process.

Instead, operations should confirm that the ERP, warehouse, and customer-facing commitment all agree.

16. When Does a Business Need Automated EDI 855 Processing?

Not every company needs advanced automation immediately. However, manual processing becomes risky as order volume and trading-partner complexity increase.

16.1 Signs Automation Has Become Necessary

For example, consider automation when teams regularly:

• re-enter EDI orders manually;
• compare inventory in spreadsheets;
• check customer prices by hand;
• acknowledge orders through several retailer portals;
• manage multiple warehouses;
• investigate repeated quantity discrepancies;
• miss acknowledgment deadlines;
• reconcile EDI status against ERP status.

Therefore, businesses should judge automation needs by operational complexity rather than company size alone.

16.2 Who May Not Need It Yet?

In contrast, a small company with only a few direct customers and no EDI requirement may not need an automated 855 workflow.

However, once major retailers or wholesale customers require structured acknowledgments, the process can become operationally significant very quickly.

Xorosoft’s broader business solutions address inventory-driven operations where order, inventory, purchasing, warehouse, and financial processes increasingly need one source of truth.

17. EDI 855 Use Cases Across Inventory-Driven Industries

Although the transaction stays the same, operational exceptions differ by industry. Therefore, each business should design acknowledgment rules around its actual fulfillment model.

17.1 Apparel and Fashion

Apparel suppliers manage style, color, size, and seasonal availability.

Consequently, one PO can contain many SKU-level differences even when the overall order appears straightforward.

17.2 Wholesale Distribution

Distributors often receive large multi-line orders.

Therefore, partial availability, customer-specific pricing, multiple warehouses, and substitute items can create detailed acknowledgment requirements.

17.3 Furniture

Furniture companies often manage longer lead times and bulky inventory.

As a result, realistic fulfillment dates can become just as important as quantity availability.

17.4 Sporting Goods and Consumer Products

Seasonality and promotions can change inventory quickly.

Therefore, suppliers need current availability before they commit quantities to retail customers.

17.5 Manufacturing

Manufacturers must consider components, production capacity, and work-order schedules.

Consequently, a requested date may depend on future production rather than finished-goods inventory alone.

Xorosoft supports several of these inventory-driven operating models across its industries pages.

18. EDI 855 in Shopify and Multi-Channel Operations

A business may sell through Shopify while also supplying wholesale or retail partners through EDI. Therefore, inventory commitments cannot operate independently by channel.

For example, a Shopify order can consume inventory moments before an EDI purchase order arrives. Conversely, a large wholesale allocation can reduce what the ecommerce storefront should promise.

Consequently, businesses need a shared inventory picture across channels.

Xorosoft connects ecommerce and ERP workflows, while its Shopify App Store listing provides additional context for merchants evaluating a connected Shopify ERP setup.

Moreover, multi-channel teams should define which inventory pools, warehouses, and allocation priorities feed each EDI acknowledgment. Otherwise, two channels may promise the same stock.

19. A Practical EDI 855 Exception Example

Consider a retailer that sends a PO with four lines.

Line	Buyer request	Supplier result
1	100 units	Accept 100
2	500 units	Accept 420
3	75 units by Oct. 10	Accept 75 for Oct. 14
4	25 units	Reject

First, the supplier accepts line 1 without a change.

Next, inventory limits line 2 to 420 units. Therefore, the acknowledgment communicates the quantity difference.

Meanwhile, line 3 has enough stock, but the warehouse cannot meet the requested date. Consequently, the supplier proposes October 14.

Finally, the supplier cannot fulfill line 4. Therefore, it communicates a rejection under the applicable partner rules.

The buyer now has a structured response before fulfillment begins. As a result, both sides can resolve the differences earlier.

20. How to Build Reliable EDI 855 Business Rules

The best implementation starts with business rules rather than code mappings. Therefore, operations, customer service, IT, finance, and warehouse teams should agree on how each exception should behave.

20.1 Define Inventory Rules

First, decide what “available” means.

For example, determine whether the calculation subtracts allocations, holds, safety stock, transfers, or marketplace commitments.

20.2 Define Pricing Rules

Next, identify the pricing source.

For example, the business may use customer contracts, price lists, promotions, or account-specific overrides.

Therefore, the system should know which source wins before it evaluates the PO.

20.3 Define Date Rules

Then, decide how the system calculates an achievable date.

For example, inventory location, production lead time, warehouse capacity, and carrier schedules may all matter.

Consequently, the 855 can represent a realistic commitment instead of a default requested date.

21. EDI 855 Implementation Checklist

Before going live, teams should verify the complete workflow.

First, confirm the correct X12 version and obtain the buyer’s implementation guide. Next, map customer IDs, ship-to locations, SKUs, line numbers, and units of measure.

Then, define supported acknowledgment types and line statuses. Moreover, document how the system should handle quantity, price, date, substitution, hold, and rejection exceptions.

After that, test accepted orders as well as exception orders. For example, test insufficient inventory, invalid SKUs, wrong prices, delayed dates, and rejected lines.

Meanwhile, verify that the downstream ERP and warehouse order reflect the final commitment.

Finally, monitor production transactions after launch. Therefore, teams can detect rejected files, unusual exception rates, or mismatched order statuses before they affect customers.

For additional operational examples, teams can review Xorosoft case studies to see how inventory-driven businesses approach connected operations.

22. Turn EDI 855 Into a Reliable Order Commitment

EDI 855 works best when it represents a real business commitment rather than a technical acknowledgment.

Therefore, suppliers need accurate inventory, customer pricing, product mappings, fulfillment dates, and trading-partner rules before they generate the response. Moreover, the order, warehouse, and financial systems should continue from that same commitment.

As volume grows, disconnected portals and spreadsheets make this process harder to control. Consequently, an integrated ERP can reduce the gap between what EDI communicates and what operations can actually execute.

Xorosoft brings inventory, purchasing, order management, warehouse operations, accounting, ecommerce, and EDI-related workflows into a connected environment for inventory-driven businesses.

If your team wants to see how that model can support its own order workflow, Book a Demo.