Skip to content
Novus Examples
edi436 B

X12 EDI 810 Invoice

An ANSI X12 810 invoice that references the 850 purchase order — ISA/GS/ST envelope with BIG, IT1 line items, and a total. The invoice twin of the purchase order, for testing EDI document flows.

Preview — first 14 linesedi
ISA*00*          *00*          *ZZ*EXAMPLESUPPLIER *ZZ*NOVUSBUYER      *260118*1015*U*00401*000000002*0*P*>~
GS*IN*EXAMPLESUPPLIER*NOVUSBUYER*20260118*1015*2*X*004010~
ST*810*0001~
BIG*20260118*INV-2026-0088*20260115*PO-2026-0042~
N1*RE*Example Supplier Inc*92*SUPPLIER-009~
IT1*1*10*EA*12.50**BP*SKU-0001~
IT1*2*5*EA*79.99**BP*SKU-0006~
IT1*3*20*EA*3.20**BP*SKU-0011~
TDS*58445~
CTT*3~
SE*9*0001~
GE*1*2~
IEA*1*000000002~

Specifications

Standard
ANSI X12 004010
Transaction
810 (Invoice)
References
PO-2026-0042
Note
synthetic

What is a .edi file?

EDI (Electronic Data Interchange), in the ANSI X12 family, is a structured plain-text format for exchanging business documents like purchase orders (850) and invoices (810) between trading partners. It is built from segments (ISA, GS, ST, …) separated by delimiters, with tightly specified element positions. It underpins much of B2B supply-chain and retail commerce.

How to use this file

Use an example X12 EDI file to test EDI parsers and translators, segment/element extraction, and mapping from EDI to JSON or XML. The parties and values here are synthetic.

How to use this file for testing

“X12 EDI 810 Invoice” is a deterministic Novus Examples fixture for Data import, Conversion testing. Realistic faker-generated datasets with documented schemas for testing import and ETL flows.

Documented properties for this file: EDI · 436 bytes. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.

Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.

Document fixtures list their internal structure (pages, fields, tracked changes, embedded objects) in the spec table. Test extractors, converters, and OCR against that known structure, and compare searchable↔scanned or format-twin companions when present.

Code examples

from pydifact.segmentcollection import Interchange  # EDIFACT

inter = Interchange.from_file("invoice-810.edi")
for seg in inter.segments:
    print(seg.tag, seg.elements)

Generated by generation/docs_realworld.py. Free for any use, no attribution required — license.