EDI 810 Explained
Brands dread preparing them and waiting for them to get cleared. Retailers can struggle with clearing and reconciling them quickly.
Modern trade solutions (like ours) take the hassle out of the invoicing process by using payment processors like Stripe. Brands can also get paid out faster since these processors offer instant payouts.
But if a retailer or a brand uses electronic data interchange (EDI) to trade, how do you send and receive invoices? That’s when you need to use EDI 810 files.
In this article, we’ll explain what EDI 810 documents are and why they’re used. We’ll also share an example of an EDI 810 document and walk you through it so that you know what to look for when you’re sending and receiving 850 documents with your partners.
What is an EDI 810 document?
The EDI 810 Invoice Transaction document is used to issue invoices between trading partners. In a retail context, it’s usually sent by brands to retailers after an order has been fulfilled.
810 documents are formatted in the American National Standards Institute (ANSI) x12 EDI standard in North America and EDIFACT in Europe. Parties who receive an 810 file usually respond with an EDI 997 Functional Acknowledgement file.
Intended benefits of EDI 810 files
EDI 810 files are electronic versions of paper invoices. For businesses that deal with a high volume of transactions with their trading partners, there are a couple of obvious benefits that come with using EDI 810 files:
- Speed and accuracy
EDI 810 electronic invoices are beneficial for retailers because they can match them against their EDI 850 Purchase Orders (POs) that were issued to brands as part of every order. PO information is included in every EDI invoice.
This is more efficient and accurate than having to manually match paper invoices against paper purchase orders. - Standard source of truth
EDI 810 files close the loop on the lifecycle of an order for retailers. An order’s life begins when an EDI 850 is issued, after which updates are made with 846 and 856 files, and finally completed with an EDI 810 file.
Having invoices issued in a standard format like EDI allows retailers to collect invoice data from multiple suppliers and aggregate them all in one place i.e. their EDI solution. This reduces the burden on a retailer’s finance team to check for invoices across multiple platforms and risk having outstanding invoices that aren’t cleared.
Drawbacks of using EDI 810
Like every other EDI file, the drawbacks of using EDI 810 far outweigh its intended benefits:
- Lack of automation
Most brands have to manually generate their EDI 810 files within an EDI solution. The reason for this is EDI providers charge per-order fees to automate EDI transactions, which is prohibitive for brands and eats into their margins.
This lack of automation makes using EDI 810 files a chore for suppliers. - Expensive and time-consuming to set up
Brands have small teams, many of whom aren’t technically proficient with legacy protocols like EDI. The EDI implementation is expensive for them and it can take 3-4 months for them to get compliant and test their EDI integration with their trading partners.
- Longer settlement cycles
EDI-based invoicing takes longer than API-based systems with instant payout processes. If a brand uses an EDI 810 file, they should expect to get paid on net 30 payment terms at minimum. We’re not against monthly or quarterly invoicing, but we do believe that brands and retailers should have the technical flexibility to settle invoices however they like.
EDI 810 example (with segments explained)
Here’s a sample EDI 810 file:
EDI 810 files are easier to understand than 850 or 856 files, but there are several nuances for invoicing that make them distinct.
As with other EDI documents, EDI 810 files are made up of segments, which are standardized sequences of data elements. Each segment has a segment identifier (ex: BIG, PID, and TDS are segment identifiers) with corresponding data elements that follow.
We’ll break down the essential segment identifiers and data elements to help you understand EDI 810 files at a glance.
ST refers to the transaction set that the EDI file refers to. In this case, it indicates that this document is an EDI 810 file.
The BIG segment contains the invoice date, the invoice number, and the corresponding purchase order number.
The IT1 loop represents the item being invoiced — it’s identified here by its UPC code and includes its unit price as well.
The PID segment identifier provides the item description for the invoiced item.
The TDS segment provides information on the total invoice amount in the 810 file. It’s the sum of the unit price of the item plus additional taxes levied.
The TXI segments are the tax items. Each type of tax has an associated code — GS represents Goods and Services Tax and SP represents State/Provincial Tax.
There are a few other segment identifiers and qualifiers we haven’t covered here, including CUR, REF, and CTT segments. If you’re curious about these segments, check out our Support article on 810 files, where we cover all the segments and data elements in detail.
Modern Dropship handles your EDI 810 Invoice Transactions (and every other EDI file)
In a pre-Internet era, EDI was the only way brands could invoice retailers for their orders.
With API-based invoicing tools and instant remittances, EDI 810 files are an outdated way for brands to invoice their trading partners. If you’re a retailer looking to attract the latest brands to your online store, you need to provide brands with the flexibility to transact with you in ways that are convenient for them.
Modern Dropship helps retailers:
- Offer multiple connection methods to brands via native Shopify, WooCommerce, and BigCommerce integrations.
- Provide flexible invoicing solutions — brands can connect their Stripe account to generate automated invoices and receive per-order payouts from their retail partners.
- Give trade experiences your suppliers will love — they can process your orders directly in their ecommerce platform.
