EDI 840 Request for Quotation: Contents, Transmission, and Response

An EDI 840 is the electronic Request for Quotation defined by the ANSI ASC X12 standard. A buyer sends it to one or more potential sellers to ask for pricing, availability, and delivery timelines on specific goods or services. Because every supplier receives the same structured document, their systems can read it automatically and respond in a matching format, which replaces paper bids, faxed spreadsheets, and re-keyed data with a traceable digital exchange.

Where the 840 Fits in a Purchase

The 840 sits at the very start of a procurement cycle. It tells the seller what the buyer wants priced: item numbers, quantities, requested delivery dates, and any special terms. Nothing about it commits the buyer to buy or the seller to sell.

That distinction matters legally. Under federal acquisition rules, a quotation is not an offer that can be accepted to form a contract. The buyer reviews the responses, and if they want to move forward, they issue a separate purchase order, which is the actual offer to buy. Only when the seller accepts that order does a contract exist.1Acquisition.GOV. 13.004 Legal Effect of Quotations Either side can walk away after the quote stage without liability.

The Full Transaction Sequence

The 840 is the first document in a chain of four X12 transactions that carry a purchase from inquiry to confirmed order:

  • EDI 840: the buyer sends the Request for Quotation.
  • EDI 843: each seller responds with pricing, quantities, and delivery commitments.
  • EDI 850: if the buyer accepts a seller’s terms, they issue a Purchase Order.
  • EDI 855: the seller sends a Purchase Order Acknowledgment confirming they can fulfill it.

Each step produces its own electronic record, so there is a documented audit trail from the first inquiry through the binding agreement.

What Goes Inside an EDI 840

Building a valid 840 means populating specific data segments, each carrying a labeled piece of information the seller’s system needs to price the request accurately.

  • BQT (Beginning Segment): sets the purpose of the document and assigns a unique reference number. Mandatory, and it appears once per transaction set.2Defense Logistics Agency. DLA BSM 840 IC
  • N1/N3 (Name and Address): identifies the legal entities involved, including the buyer, seller, and ship-to location. Errors here can route a quote response to the wrong division.
  • PO1 (Baseline Item Data): the heart of the request. Each PO1 loop specifies an item number, unit of measure, and quantity. Fifteen parts means fifteen PO1 loops.
  • PID (Product/Item Description): free-text or coded descriptions that supplement the PO1 data.
  • REF (Reference Identification): links the request to internal tracking numbers like project IDs or department codes. Common qualifiers include “DP” for department and “ZZ” for identifiers the trading partners have mutually defined.
  • ITD (Terms of Sale): can specify requested payment terms like net-30 or net-60. Optional, and many implementations leave it out.

Accuracy in each segment is important because the seller’s system often auto-populates the response from what you send. A wrong unit of measure in PO1 produces a quote priced per case when you meant per unit.2Defense Logistics Agency. DLA BSM 840 IC

The 840 itself travels inside a set of nested X12 envelopes: an interchange envelope (ISA/IEA) that identifies sender and receiver, a functional group envelope (GS/GE), and the transaction set envelope (ST/SE) around the document itself. Translation software handles this layering; you don’t build the envelopes by hand.

How the Document Gets Sent

You can’t just email an EDI file. Three pieces of infrastructure sit between your system and your trading partner’s.

Translation and ERP Mapping

EDI translation software converts data from your Enterprise Resource Planning system into the flat-file format X12 requires. That conversion is called mapping, and it’s where most implementation problems live. Your database might store a part number in one field; the 840 needs it in a specific position within a PO1 segment. Different trading partners use optional fields differently, categorize products differently, and sometimes use non-standard date formats, so a map built for one partner rarely works untouched for another.

Choosing a Communication Channel

Once the 840 is built, it needs a secure path to the recipient. Three options dominate:

  • AS2 (Applicability Statement 2) is an HTTP-based protocol that encrypts EDI files with digital certificates and returns a Message Disposition Notification as proof of delivery. Real-time, with built-in non-repudiation, and preferred for high-volume trading partners.
  • SFTP encrypts files during transfer using SSH. Simpler to set up than AS2 but lacks built-in delivery confirmation, so you may need a separate process to verify receipt.
  • A Value-Added Network (VAN) acts like a secure mailbox. You drop your 840 in; the recipient retrieves it. The VAN handles routing, identity verification, backup, and compliance checks, at a per-transaction cost.

The Trading Partner Agreement

Before any data changes hands, both sides sign a Trading Partner Agreement (TPA) that spells out the technical and legal ground rules: which X12 version to use, which communication protocol, server uptime expectations, deadlines for acknowledgments, backup delivery methods, and who bears liability for transmission errors.3North American Energy Standards Board. Electronic Data Interchange Trading Partner Agreement Skipping this step invites finger-pointing the first time something breaks. The X12 version you’ll use is set here; many partners still run on older versions like 4010 or 5010 even though newer releases exist.

What Comes Back After You Send an 840

When the file lands on the receiving server, an automated validation check runs against the rules in the TPA. The system verifies that required segments are present, fields aren’t truncated, data types match, and the structure hasn’t been corrupted in transit.

If the file passes, the recipient’s system returns an EDI 997 Functional Acknowledgment. That is a technical receipt confirming the file arrived intact and could be read. It does not mean the seller agrees to your terms or plans to send a quote. It only says the file was syntactically valid.4Defense Logistics Agency. DLMS Implementation Convention 997 – Functional Acknowledgment

If validation fails, the 997 carries error codes pointing at what went wrong. Common issues include:

  • A mandatory segment is missing, such as the BQT.
  • A data element is too short or too long for the standard’s requirements.
  • A qualifier code is invalid or not supported by that partner’s implementation.
  • Segments arrived in the wrong order.

Status codes at the transaction set level tell you where you stand: “A” for accepted, “E” for accepted with errors noted, “R” for rejected. A rejected transaction has to be corrected and retransmitted. Many large buyers impose chargeback fees for failed or misformatted documents to cover the cost of manual intervention, with penalties around $100 per non-compliant document common in retail supply chains.

Keep a log of every 997 and its status. It’s your audit trail when someone later disputes whether a request was received.

The 843 Response and What Follows

After a seller processes your 840, they respond with an EDI 843. It mirrors the structure of the original request but fills in the seller’s pricing, available quantities, and confirmed delivery dates.5Texas Instruments. Response to Request for Quotation (843) Because both documents share the same segment layout, your system can compare the response against your original request automatically and flag any discrepancies in pricing or lead time without anyone reconciling spreadsheets by hand.

If you like what the 843 offers, the next step is an EDI 850 Purchase Order. That’s where the transaction shifts from inquiry to commitment; once the 850 is issued and accepted through an 855, a contract exists.6Infor Documentation. EDI 840 Request for Quote Inbound and EDI 850 Purchase Order Inbound The whole sequence, which used to take weeks of mailed bids and phone calls, can now run in hours.

Legal Status of the Document

An EDI 840 carries legal weight as an electronic record. The E-SIGN Act provides that a contract or record cannot be denied legal effect solely because it’s in electronic form, and the same protection covers electronic signatures used in forming contracts.7Office of the Law Revision Counsel. 15 USC 7001 – General Rule of Validity Your EDI transmissions are treated the same as paper documents in court, provided you can authenticate them.

The 840 doesn’t obligate either party. It’s a solicitation, not an offer. Under UCC Article 2, a seller’s written response can become a “firm offer” that can’t be revoked for up to three months if the seller is a merchant, the response is signed, and it explicitly promises to hold the price open.8Legal Information Institute. UCC 2-205 Firm Offers The request itself carries no such weight. If no one responds, you’ve lost nothing legally. If you don’t like any of the 843s that come back, you can walk away.

The TPA is where the real legal teeth are. Under a standard TPA, the sender is liable for errors caused by their provider during transmission, while the receiver is liable for errors on the retrieval side.3North American Energy Standards Board. Electronic Data Interchange Trading Partner Agreement Digital codes attached to each document authenticate the origin, similar to a signature.

Security Baseline

An 840 can carry sensitive procurement data: what you’re buying, in what volumes, and from whom. That makes the transmission channel and the systems on both ends worth protecting.

If you’re doing business with federal agencies, cryptographic modules used to protect that data must be validated under FIPS 140-3, the current U.S. government standard for cryptographic modules protecting sensitive information. The standard defines four escalating security levels covering module design, physical tamper resistance, and key management.9Computer Security Resource Center. FIPS 140-3, Security Requirements for Cryptographic Modules Even outside the federal contracting world, FIPS-validated encryption is a reasonable baseline for high-value procurement traffic.

Your protocol choice sets your encryption floor. AS2 encrypts end-to-end with digital certificates and provides non-repudiation through signed Message Disposition Notifications. SFTP encrypts in transit but doesn’t inherently prove delivery. VANs handle encryption for you but add a third party to the chain, so your security is only as strong as the VAN’s own infrastructure. Whichever channel you pick, the TPA should spell out the minimum encryption standard both sides agree to maintain.