EDI 810 invoices explained: the document that actually gets you paid

The 850 gets the attention because it's the order. The 856 gets the attention because the retailer will fine you if it's late. The 810 is the one nobody talks about, and it's the only one that actually gets you paid.

An EDI 810 is an electronic invoice. When you ship a retailer's purchase order, you send the retailer an 810 that says: for this PO, here is what we shipped, here is what you owe, here are the terms. The retailer's accounts-payable system matches it against the PO and the ship notice, and if everything lines up, it goes into their payment run.

That "if everything lines up" is where most of the trouble is.

What's in an 810#

Stripped down, an invoice has five parts, and each one has a job:

1. The header — your invoice number, the invoice date, and the retailer's PO number. The PO number is the key the retailer matches on. Get it wrong and the invoice has nothing to attach to.
2. The parties — who's billing (you), who's being billed (the retailer), and often who the goods shipped to. Retailers identify these with codes they assign, not with addresses, so these have to be the codes from their vendor setup.
3. The lines — one per item shipped, with quantity, unit price, and the item identifier the retailer uses (their SKU, the UPC, or both). The quantity here is what you shipped, not what they ordered.
4. The totals — the sum of the lines, plus or minus any allowances, charges and freight.
5. The terms — net days, any discount for early payment, and the dates those run from.

Different retailers ask for different extras (a TSCA statement, a department number, a "bill of lading" reference), but those five are the skeleton.

The three-way match, and why your invoice fails it#

The retailer isn't going to pay an invoice because it arrived. They're going to pay it because it matches two other things they already have:

• the PO they sent you (the 850), and
• the ship notice you sent them (the 856).

So the invoice has to agree with both. The classic ways it doesn't:

Invoicing the order instead of the shipment. You received a PO for 12, shipped 10 because of a backorder, and invoiced 12. The 856 says 10. The invoice goes into a dispute queue. Invoice what shipped.

Invoicing before shipping. Some systems can generate the 810 as soon as the order is created. The retailer's AP system sees an invoice with no matching ship notice and either rejects it or sits on it. The 810 should follow the 856, not precede it.

A price that isn't the PO price. Your Sellercloud price list got updated; the retailer's PO still carries the price from their cost agreement. The retailer will pay the PO price. If your 810 says otherwise, at best they short-pay, at worst they reject.

Wrong item identifiers. Line 1 on the PO was their SKU 48811. Your invoice says your SKU GV-4411. Even if the UPC is also on the line, some AP systems only match on the retailer's own number.

One invoice for several shipments, or several for one. Most retailers want one 810 per shipment (and one 856 per shipment). Combining or splitting breaks the match.

Allowances and charges: where the money moves#

Retailers routinely take money off your invoice: a defective allowance, a new-store allowance, a marketing contribution, freight terms. Some of these are supposed to appear on the 810 as allowance lines (so your total already reflects them); others the retailer deducts on their side.

Which is which is in your vendor agreement, and it matters. If your contract says a 2% allowance is "off invoice," and your 810 doesn't show it, the retailer will deduct it anyway — and now your receivable in your own books is 2% higher than what you'll ever collect. Set the allowance up once so it's applied automatically, rather than reconciling it every month.

The 997 isn't payment#

When you send the 810, you'll get a 997 back. That is the retailer's system saying "we received a well-formed file." It is not acceptance of the invoice, and it has nothing to do with payment. An invoice can get a clean 997 and still be rejected a day later for a price mismatch.

The place to watch for actual acceptance varies: some retailers send an 864 text message, some send an 820 remittance advice when they pay, some only tell you in their vendor portal. Know which one your retailer uses so that "no news" doesn't quietly become "no payment" ninety days later.

How this looks with Sellercloud#

In a Sellercloud setup, the 810 is built from the shipped order — the quantities and tracking that are already on the order once it's been processed. That is the right source, because it keeps the invoice tied to what left the building.

What has to be right for it to work:

• the order's channel PO number is the retailer's PO, exactly as sent;
• the prices on the order are the PO prices, not a list price that was updated later;
• the order is fully shipped (or you're invoicing a partial shipment deliberately) before the invoice generates;
• any required retailer-specific fields — vendor number, department, the TSCA statement for Rooms To Go, and so on — are set up once at the connection level so they go out on every invoice.

interSend generates the 810 after the 856 for each shipment, from the Sellercloud order, and you can see both documents side by side against the original 850 for any PO. When a retailer short-pays, that side-by-side view is usually where the answer is.

Checklist before you turn invoicing on#

• Does the retailer want one invoice per shipment, or per PO?
• Which item identifier do they match on?
• Which allowances are off-invoice, and are they configured?
• What are their payment terms, and do they expect you to state them on the 810?
• How do they tell you an invoice was rejected — 864, 824, portal, email?

Answer those five before the first live 810 and you'll spend a lot less time in the deductions report.