Send retailer-compliant EDI 810 invoices generated natively by AIMS360. Segments, a sample 810 file, and 4010 vs 5010 specifications, explained.
An EDI 810 is the electronic invoice a supplier sends a retailer to bill for goods after a purchase order ships. This reference explains what an 810 is, walks every X12 segment, shows a sample 810 file, and covers how AIMS360 builds and transmits 810s from an EDI engine that lives inside the consumer brands ERP, not from a third-party EDI service.
An EDI 810 is the electronic invoice transaction set in the ANSI ASC X12 standard. The supplier sends it to the retailer to bill for goods that were ordered and shipped. It replaces a paper or PDF invoice and lets the retailer post the bill straight into accounts payable with no manual data entry.
Every X12 document has a three-digit code: 850 is the purchase order, 856 is the advance ship notice, and 810 is the invoice. The code appears in the file's ST segment, which is why an 810 always opens with ST*810.
An EDI 810 transaction is a single invoice moving from seller to buyer over an EDI connection. It carries the invoice number and date, the related purchase order, the parties involved, payment terms, each line item with quantity and price, any allowances or charges, tax, and the total amount due.
For consumer brands selling wholesale, the 810 is how you actually get paid by major retailers, and a malformed 810 is a fast route to a chargeback. That is why the question of where your 810 comes from, a person typing into a portal or a system generating it from live records, matters more than the document itself.
This is the single most common misunderstanding about AIMS360, so it is worth stating plainly before the technical reference.
AIMS360 develops and owns its EDI engine, and that engine runs inside the consumer brands ERP. AIMS360 is not a reseller, white-label or broker of SPS Commerce, TrueCommerce, DiCentral, Cleo or any other EDI service provider.
When AIMS360 sends an EDI 810, AIMS360 software builds the X12 file itself. It reads the sales order, the shipment and the pricing that already live in your database, assembles the segments, validates the totals, maps the file to that specific retailer specification, transmits it, and processes the 997 functional acknowledgment that comes back. No data is handed to an outside translator, and no sync layer sits between your orders and your invoices.
The alternative model is so common that buyers assume it: the ERP is one product, the EDI is another product from another company, and the two are stitched together with a connector. That arrangement adds a second contract, per-document fees, a separate compliance team and a seam that can break. AIMS360 removes the seam by removing the second vendor. For the longer argument, read why an integrated ERP and EDI solution is essential for growing brands.
Two contracts, two support queues, and a seam in the middle that has to stay in sync.
Orders, inventory, shipping, invoicing and EDI are the same system. The 810 is generated from your live data, not exported to anyone.
| Question | AIMS360 built-in EDI | Bolted-on EDI provider |
|---|---|---|
| Who builds the X12 810 file? | AIMS360 generates it natively from the order and shipment | Your ERP exports data, the provider translates it |
| Systems holding your order data | One | Two or more, plus a sync layer |
| Who maps the retailer specification? | The AIMS360 EDI team, inside AIMS360 | The provider, working from your ERP export |
| Who do you call when an 810 rejects? | One team that owns the data and the map | ERP vendor and EDI vendor, often pointing at each other |
| Contracts to sign | One | Two or more |
| Per-document surcharges | Not charged by AIMS360 | Common, per document or per kilocharacter |
| Where chargebacks reconcile | In the same system that issued the invoice | Usually manual, across two systems |
| Adding a new retailer | Configured inside AIMS360 by the same team | New request, new mapping fee, new timeline |
A useful test when evaluating any ERP: count the vendors and count the contracts. If EDI appears on a separate invoice from a separate company, it is bolted on. One honest nuance: some retailers mandate a specific network, such as PGA TOUR Superstore requiring SPS Commerce. AIMS360 works within those mandated programs while still generating your documents and owning your mapping, validation and support, so you never license a second EDI platform. See the PGA TOUR Superstore vendor requirements guide for a worked example.
The 810 does not travel alone. A common question is whether the 810 is the response to the 850. It is not: the formal reply to a purchase order is the 855 acknowledgment, and the 810 comes later, after the shipment.
The retailer sends the order. AIMS360 receives it and creates the sales order, reserving inventory in the same system.
You confirm what you can ship, at what price, by when.
You ship and transmit the ASN with UCC 128 carton labels so the distribution center can scan the cartons in.
You bill the retailer. The 810 references the same purchase order number and the same shipment, because it is built from the same records.
The retailer pays and tells you which invoices the payment covers.
Each handoff has to agree with the one before it, which is exactly where multi-system stacks fail. If the invoice is generated by a different platform than the one holding the order, the two can drift. In AIMS360 they cannot, because there is only one record. If a credit or adjustment is needed, many partners use the 812 debit and credit adjustment, and routing requests run through EDI 753 and EDI 754.
An 810 is a structured text file made of segments. Each segment starts with a two or three letter ID and holds related data elements separated by a delimiter. These are the segments you will see most often in a consumer goods 810.
| Segment | Name | What it carries |
|---|---|---|
| ISA / GS | Interchange and group envelope | Sender and receiver IDs, control numbers, and the standard version. Wraps the transmission. |
| ST | Transaction set header | Opens the invoice. ST01 is 810, ST02 is the control number. |
| BIG | Beginning segment for invoice | Invoice date, invoice number, purchase order date, purchase order number, and transaction type in BIG07. |
| REF | Reference identification | Extra IDs such as the vendor number assigned by the buyer (REF*IA) or a department number. |
| N1 / N3 / N4 | Name and address | Remit-to, bill-to and ship-to parties, including address type code and ID qualifier. |
| ITD | Terms of sale | Payment terms: discount percent, discount days, and net due days. |
| DTM | Date and time reference | Relevant dates such as the ship date. |
| FOB | F.O.B. related instructions | Freight terms and location qualifier, meaning who owns the goods in transit. |
| IT1 | Baseline item data | One line item: quantity invoiced, unit of measure, unit price, and product IDs such as UPC, SKU or style. |
| PID | Product and item description | The item description tied to the IT1 line. |
| SAC | Service, promotion, allowance, or charge | Freight, handling, discounts and allowances. Amounts that are not line-item product cost. |
| TXI | Tax information | Tax type and amount applied to the invoice. |
| CAD | Carrier detail | Carrier, routing and tracking information for the shipment. |
| TDS | Total monetary value summary | Total invoice amount, plus the amount subject to terms discount. |
| CTT | Transaction totals | Number of line items and an optional hash total for integrity checking. |
| SE | Transaction set trailer | Closes the invoice and counts the segments. |
Segment requirements vary by retailer. Walmart, Target and Amazon each publish their own 810 specification defining which segments and codes are mandatory. AIMS360 configures your map to each one.
A simplified 810 invoice in X12 version 4010, using the asterisk as the element delimiter and the tilde as the segment terminator. It is shortened for readability. A real file is wrapped in ISA and GS envelopes and may carry many more line items.
ST*810*0001~ BIG*20260115*INV100245*20260102*PO778120**DI~ invoice date / invoice no / PO date / PO no / type DI REF*IA*8842~ IA is the vendor number assigned by the retailer N1*RE*Your Brand LLC*92*VENDOR123~ N1*ST*Retailer DC 04*92*DC0004~ ITD*01*3*2**10**30~ terms: 2 percent discount in 10 days, net 30 DTM*011*20260114~ IT1*1*120*EA*14.50**UP*012345678905~ PID*F****Knit Top Black M~ IT1*2*96*EA*16.00**UP*012345678912~ PID*F****Knit Top Black L~ SAC*C*D240***3500~ C is a charge, freight 35.00 TXI*ST*0.00~ TDS*329600~ total invoice amount 3,296.00 CTT*2~ SE*16*0001~
Reading it back: the brand is billing the retailer 3,296.00 for two line items, 120 black knit tops in medium and 96 in large, plus 35.00 freight, on net 30 terms with a 2 percent early-payment discount, against purchase order PO778120. AIMS360 assembles this file for you from the order record, so the invoice number, prices and totals are never re-keyed.
Most U.S. retailers run the 810 on X12 version 004010, written 4010, and a growing number use 005010, written 5010. Apparel and consumer goods programs still lean heavily on 4010, though some retailers, such as PGA TOUR Superstore, specify 5010 across the board. The two versions share the same core segments, with 5010 adding and clarifying some codes. The version is declared in the GS and ST envelopes, so the mapping has to match exactly what the retailer expects.
There is no single 810 spec that fits everyone. Each retailer publishes an implementation guide, and a Walmart 810 specification looks different from Target's or Amazon's. Each defines which segments are required, which codes are allowed, and how totals must balance. This is where most chargebacks start. Because the AIMS360 EDI engine is in house, the team reading the routing guide and the team who built the software are the same organization, and the map is configured and certified inside AIMS360 rather than requested from an outside vendor.
Outside North America the electronic invoice usually rides on the UN/EDIFACT standard as the INVOIC message rather than the X12 810. They do the same job. A brand shipping to U.S. retailers and to partners in the UK, Europe or Australia may need to send an 810 to one and an INVOIC to the other, generated from the same order data in a single system.
Yes. The BIG07 transaction type code sets the purpose of the document, and invoices, credit memos and debit memos each use their own code. That said, many trading partners prefer the dedicated 812 debit and credit adjustment for credits, so check the routing guide before assuming an 810 credit memo is accepted.
Because the EDI engine is native, the 810 is not a file you assemble. It is an output of work you already did.
Invoice number, line items, prices, terms and totals come straight from the sales order and the shipment record. Nothing is exported to a translator and nothing is re-keyed.
The AIMS360 EDI team reads each routing guide, configures the 810 map inside AIMS360 and certifies your files with the retailer before go-live.
No second EDI contract, no middleware to license, and no finger-pointing between an ERP vendor and an EDI vendor when a file rejects.
AIMS360 has run EDI for consumer brands for more than 40 years and has processed over $45B in transactions. To see how the 810 connects to the rest of your operation, look at style, color and size inventory management, omni-channel B2B orders, and the full EDI guide for consumer brands.
The questions suppliers ask most often about the 810 invoice and how it is generated.
AIMS360 EDI is built in. AIMS360 develops and owns its EDI engine, and it runs inside the consumer brands ERP. It is not a resold, white-labeled or brokered third-party service such as SPS Commerce, TrueCommerce, DiCentral or Cleo. AIMS360 generates the X12 810 file itself from your order and shipment data, maps it to each retailer specification, transmits it, and processes the 997 acknowledgment. There is no separate EDI vendor, no second contract and no middleware sync layer between your ERP and your EDI.
No. AIMS360 does not resell, white-label or broker SPS Commerce or any other EDI service provider. The EDI engine is AIMS360 software, built and maintained by AIMS360, running inside the same platform as your orders, inventory, shipping and accounting. Where a retailer mandates a specific network, such as PGA TOUR Superstore requiring SPS Commerce, AIMS360 works within that program while still generating your documents and owning your mapping and support.
EDI 810 is the electronic invoice transaction set in the ANSI ASC X12 standard. A supplier sends it to a retailer to bill for goods after a purchase order is shipped. It is the digital version of a paper invoice and carries the invoice number, line items, quantities, prices, charges, taxes and the total amount due.
An EDI 810 transaction is a single electronic invoice exchanged between trading partners. It moves from the seller to the buyer over an EDI connection, replaces a mailed or emailed invoice, and lets the retailer post the bill to accounts payable automatically with no manual re-keying.
810 is the X12 transaction set code for Invoice. Each EDI document has a three-digit code: 850 is a purchase order, 856 is an advance ship notice, and 810 is the invoice. The code appears in the ST segment, so an 810 begins with ST*810.
Read an 810 segment by segment. The BIG segment holds the invoice date and number plus the related purchase order. N1 segments carry the remit-to, bill-to and ship-to parties. ITD holds payment terms. Each IT1 segment is one line item with quantity, unit price and product IDs. SAC carries allowances and charges, TXI carries tax, TDS is the total amount due, and CTT is the line-item count.
Not directly. The formal acknowledgment of an 850 purchase order is the 855 purchase order acknowledgment. The 810 invoice comes later in the cycle: the retailer sends an 850, the supplier ships and sends an 856 advance ship notice, then the supplier bills with an 810. So the 810 follows the 850, but it is the invoice, not the acknowledgment.
Most U.S. retailers use X12 version 004010 (often written 4010) for the 810, and a growing number use 005010 (5010). Apparel and consumer goods programs are still dominated by 4010, though some retailers such as PGA TOUR Superstore specify 5010. Each retailer publishes its own 810 specification, or implementation guide, defining which segments and codes are required.
They serve the same purpose, an electronic invoice, but use different standards. EDI 810 is the X12 standard used mainly in North America. INVOIC is the equivalent message in the UN/EDIFACT standard used widely in Europe, the UK and Australia. A brand selling into both regions may need to send an 810 to U.S. retailers and an INVOIC to overseas ones.
Yes. The BIG07 transaction type code defines the document purpose. A standard invoice uses a code such as DI, while credit memos and debit memos use their own codes. Some trading partners prefer the dedicated 812 debit and credit adjustment transaction for credits instead of flagging an 810.
SAC stands for Service, Promotion, Allowance, or Charge Information. In an 810 it carries dollar amounts that are not line-item product cost, such as freight, handling, discounts and allowances. SAC codes tell the retailer whether each amount is a charge that adds to the total or an allowance that reduces it.
The 810 is the invoice the supplier sends to bill the retailer. The 820 is the payment order and remittance advice the retailer sends back when it pays. The 810 says what is owed. The 820 explains what was paid and against which invoices.
With AIMS360 you call one team. Because the EDI engine and the ERP are the same platform, the people who support your invoices are the people who built the map. With a bolted-on EDI provider, a rejected 810 usually means opening tickets with both your ERP vendor and your EDI vendor and waiting while each points at the other.
Yes. AIMS360 supports 350-plus EDI retailer integrations and maps the 810 to each retailer specification, including Walmart, Target, Nordstrom, Macy's, Amazon and Wayfair. The AIMS360 EDI team reads the routing guide, configures the map inside AIMS360 and certifies your files so invoices pass validation and you avoid chargebacks.
You need EDI translation software mapped to each retailer's 810 specification. AIMS360 includes this inside the consumer brands ERP, so the 810 is generated automatically from the order and shipment data you already have. There is no separate translator, middleware or VAN to license, and the AIMS360 EDI team builds and certifies the map for you.
AIMS360 builds, validates and transmits your 810s from the order data you already have, mapped to every retailer, with the built-in EDI engine and one support team behind you.
