Skip to main content

EDI 810: Invoice

The supplier’s bill for goods or services delivered against a purchase order. Supplier to buyer. This page covers what the 810 is for, the segments you meet when you open one, the documents it travels with, where it tends to go wrong, and how it moves over AS2 into your systems on Files.com, which receives, parses, validates, and routes it as configuration.

No credit card required · 7-day free trial · Live in minutes

#1 MFT vendor in Gartner Peer Insights
Trusted by 4,000+ companies
Every protocol included

What The 810 Is For

The 810 is the invoice. Once goods ship, the supplier sends it to the buyer to request payment, and it carries the invoice number and date, the purchase order it bills against, the buyer and remit-to parties, each line item with quantity and price, any allowances or charges, and the total amount due.

Large buyers match the 810 against the 850 they sent and the 856 they received before they pay. A line that does not reconcile across the three, a quantity billed that was never shipped, or a price that differs from the PO, is what turns an invoice into a dispute. The 810 is paid with an 820, which references the invoice numbers it settles.

The Segments You Meet First

In document order, the segments that carry the 810's meaning. A partner's implementation guide says which are required and which fields each must hold.

BIG

Beginning segment for invoice: invoice date and number, and the purchase order date and number it bills against.

REF

References such as a bill of lading or department number.

N1

Parties: the buyer, ship-to, and remit-to, one loop each.

IT1

An invoice line item: quantity invoiced, unit, unit price, and product identifiers.

TDS

Total monetary value summary: the invoice total.

SAC

Service, promotion, allowance, or charge, at the line or invoice level.

CTT

Transaction totals: the number of IT1 lines.

Where It Goes Wrong

Three-way matching is the whole game. An 810 that references a PO number the buyer’s system does not recognize, or bills a quantity that exceeds what the 856 said shipped, stalls in accounts payable. Allowances and charges in SAC segments are the other trap: a freight charge the PO did not authorize is a short-pay waiting to happen.

The Documents It Travels With

The 810 rarely moves alone. These are the documents that precede, answer, or settle it.

850 · Purchase Order

A buyer’s order to a supplier: the items, quantities, prices, dates, and ship-to locations.

See The 850

856 · Ship Notice / Manifest (ASN)

The advance ship notice: what is in the shipment, how it is packed, and how it is labeled, sent before it arrives.

See The 856

820 · Payment Order / Remittance Advice

A payer’s notice of payment: which invoices are being paid, for how much, and how.

See The 820

812 · Credit / Debit Adjustment

A notice that an amount owed is being adjusted up or down, with the invoice it applies to and the reason.

See The 812

997 · Functional Acknowledgment

The receipt that says an EDI transmission arrived and was parsed, with any syntax errors found.

See The 997

How The 810 Moves On Files.com

A partner sends the 810 over AS2, SFTP, or FTPS, and it lands in that partner’s inbox folder on Files.com with the transport receipt recorded. From there it is a workflow, not a project: TransformScript parses the X12 natively into the JSON, CSV, or XML your ERP or WMS reads, content validation flags a document whose contents are wrong before anything ingests it, and an automation routes the result to the system and the people who act on it.

Outbound is the mirror image. Your system exports its record, TransformScript builds the 810 the partner’s guide specifies, and the file dropped in the partner’s outbox goes out over AS2 with automatic retries until the MDN confirms delivery. Every transmission in both directions is in the audit log, and delivery monitoring alerts when a 810 that was due never arrives. The full picture is on the EDI software page.

EDI 810 Questions

What teams ask about the 810 and how it moves on Files.com.

An EDI 810 is the X12 invoice. A supplier sends it to a buyer after shipping to request payment, referencing the purchase order it bills against and listing each line, the charges, and the total due. Buyers match it against the 850 and 856 before paying with an 820.

The 810 asks for payment; the 820 makes it. The 820 Payment Order/Remittance Advice tells the supplier which invoices are being paid, for how much, and by what method.

The 810 references one purchase order in its BIG segment. Consolidating several orders into one invoice is a trading-partner agreement, and many buyers require one 810 per PO so the three-way match stays simple.

Yes. Files.com is a standards-compliant RFC 4130 AS2 endpoint, and a 810 sent by a trading partner lands in that partner’s inbox folder with a signed MDN receipt returned to the sender. Partners who exchange over SFTP or FTPS connect to the same platform and the document lands in the same place.

Yes. TransformScript parses the X12 810 natively and writes the JSON, CSV, or XML your systems ingest, as a step in the workflow that fires when the document arrives. Outbound, the same engine builds a 810 from your system’s export and drops it in the partner’s outbox for delivery.

Exchange The 810 Without The Legacy Stack

Start the 7-day trial, turn AS2 on, and exchange certificates with your partner. The 810 lands in their folder, parses into the record your system reads, and every transmission carries a signed receipt.

No credit card required • Free for 7 days • Live in minutes