EDI 865 purchase order change acknowledgment: two uses, one transaction set

BCA is the header, and it is where the two uses diverge

BCA is the beginning segment for a purchase order change acknowledgment. BCA01 is the transaction set purpose code, BCA02 the acknowledgment type code, BCA03 the purchase order number, and BCA06 a release number where one applies. The acknowledgment type code in BCA02 draws on the same family of values as BAK02 on an 855, so a document that acknowledges with detail and change looks structurally similar. The distinguishing question is whether an 860 was ever sent for this order. If none was, an inbound 865 is a supplier proposing a change on its own initiative.

• BCA01 transaction set purpose code
• BCA02 acknowledgment type code, from the same family as BAK02
• BCA03 purchase order number
• BCA06 release number where the order is a release against a blanket

Line detail reuses POC and ACK

An 865 carries POC segments to state what is changing on each line and ACK segments to state the status of the line, which is the same ACK01 line item status code vocabulary used on an 855. That reuse is convenient for a translator and misleading for a person: the codes read like an acceptance of the order when they may be an acceptance of a change, or a counter proposal. Always resolve the line back to a purchase order number, a line number, and the version of that line the buyer last authorised before deciding what the code means.

Never let a seller initiated change post automatically

The commercial risk in the 865 is not technical. A supplier initiated date or quantity change that flows straight into the ERP silently converts a proposal into an internal commitment, and nobody signed for it. Route inbound 865 documents that do not correspond to an outstanding 860 into a buyer decision queue with an owner and an ageing rule. The buyer accepts, rejects, or counters, and only the accepted result becomes the current commitment.

Keep four values distinct on every changed line

Whether a change arrives as an 865 or as an email, the record needs to answer four questions separately: what was ordered, what the supplier proposed, what the buyer decided, and what is now committed. Collapsing those into one editable field is what makes a late delivery unarguable at the wrong moment, because the original agreement is no longer in the record. Store each with an owner and a timestamp and derive the commitment from the decision.

Where Pacteva fits

Pacteva runs exactly this decision loop for suppliers that are not on an EDI connection. A supplier proposes a quantity, price, or date change at line level through a secure accountless link, the proposal lands in a buyer queue rather than in the order, and the buyer resolves it explicitly. The ordered value, the proposal, the decision, and the resulting commitment are stored as separate facts with attributable history. Pacteva does not receive or send an 865, and it does not write to your ERP unless a configured integration verifies the write.

Validate the workflow with one real purchase order

Before buying or replacing software, run one representative multi-line PO from reviewed source through supplier response and buyer resolution. Include at least one accepted line, one proposed date or quantity change, and one delivery or reminder edge case. Confirm that every participant can identify the current owner and next action, that the original order remains unchanged, and that the final commitment can be exported and traced to its response and decision. Also verify the supplier experience on a normal phone and desktop browser, revoke and reissue a response link, inspect a failed delivery, and test the role boundary with a non-owner buyer. This evidence is more useful than a feature checklist because it exposes adoption friction, hidden authority, and incomplete system boundaries before the workflow reaches production volume.