Synthetic Invoice Data
Synthetic training data — no real PII, fully coherent identities
Generate synthetic contractor and trade invoices — seven line items, a subtotal-to-total tax chain, and a full remittance block with bank routing and account number. Training data for AP automation and vendor-payment fraud detection.
56
Fields per document
1
Page
Commercial
Category
What this document is
This is the trade and contractor invoice design: vendor header with EIN and website, bill-to block with a customer account, invoice and PO numbers, payment terms, up to seven line items with quantity, unit price and extended amount, a subtotal-tax-total chain, and a remittance block naming the bank, routing number and account number to pay into. It is the shape of invoice that dominates construction, field services and the trades — the segment where accounts-payable automation sees the highest volume and the highest error rate.
Why generate synthetically
The fifth invoice design in the catalog exists for one reason: layout robustness. An extraction model trained on a single invoice template scores beautifully on that template and falls apart on the next vendor, and AP teams do not get to choose which template arrives. Generating the same commercial semantics — vendor, customer, lines, tax, total, remittance — across visually distinct designs turns template overfitting into something you can measure instead of something you discover in production.
What makes synthetic data useful
Each invoice is arithmetically sound: quantity times unit price gives the line amount, the lines sum to the subtotal, the tax rate applies to the subtotal, and the total and balance agree. Line-item count varies per invoice, with three lines on every document tapering to a seventh on 18.6%. Payment terms follow a realistic spread led by Net 30 at 36.8% and including the 2/10 Net 30 early-payment discount that AP systems most often mishandle, and remittance is split across wire, ACH, check and card at roughly a quarter each.
Training challenges
Three columns of numbers sit side by side — quantity, unit price, extended amount — and swapping the last two produces a document that still looks like an invoice, which is why column association matters more than character accuracy on this page. Below the lines, subtotal, tax, total and balance are four currency values in adjacent labelled rows, and the tax rate is a percentage stored as text next to them. The remittance block adds a different kind of difficulty: routing and account numbers are long digit strings with no checksum visible to a reader, they must be attached to the right bank name, and in the real world they are the exact target of vendor-impersonation fraud — so an extractor that transposes two digits silently misdirects a payment.
Who uses this data
Accounts-payable automation and invoice-capture vendors, procure-to-pay platforms, construction and field-service ERP integrators, and payment-fraud teams training detection for vendor bank-detail substitution — the attack that starts with an invoice whose remittance block has been altered.
Document complexity profile
56 fields on a single page: 28 text, 18 currency, 7 number, 2 date and 1 employer identification number, joined by 50 annotation relations. A seven-row by four-column line-item table with variable occupancy sits between a vendor and customer header and a four-line tax-and-total chain, followed by a remittance block. Totals derive from the line items, so the page carries internal arithmetic a validator can check.
Key stats from our synthetic corpus
Quantitative characteristics of the Invoice documents our generator produces.
| Metric | Value | Detail |
|---|---|---|
| Line items per invoice | 3 to 7 | Lines one through three are populated on every invoice; occupancy falls to 79.1%, 56.8%, 38.7% and 18.6% for lines four through seven. Variable table height with a ruled grid below the last row is the standard failure mode for line-item extraction. |
| Most common payment terms | Net 30 (37%) | Terms are Net 30 on 36.8%, Net 60 on 14.8%, Net 45 on 14.3%, 2/10 Net 30 on 13.6%, Net 15 on 10.3% and Due on Receipt on 10.1%. The 2/10 Net 30 early-payment discount is the term AP systems most often parse as a plain Net 30 and then miss the discount window. |
| Invoices with a PO number | 71.6% | 71.6% of invoices reference a purchase order and 28.4% do not. PO presence decides which matching path an AP system takes — three-way match or non-PO approval routing — so misreading it misroutes the whole document. |
| Remittance method spread | 4 kinds | Wire transfer 28.9%, ACH 25.1%, check 23.1% and credit card 22.9%, each with bank, routing and account details printed on the page. Long unchecksummed digit strings attached to a named institution are the highest-consequence extraction on the invoice. |
| Line quantity distribution | 1 or 2 on 57% | Quantities are 1 or 2 on roughly 57% of lines with a tail out past 10. Small integers in a narrow column adjacent to two currency columns are easy to read and easy to attach to the wrong field. |
How this document co-occurs with others
Rates at which identities in our corpus that produce a Invoice also produce other documents.
| Correlation | Rate | Detail |
|---|---|---|
| Same semantics, classic design | 100% | The classic invoice carries the same vendor, customer, line and total structure in a different layout. Paired evaluation across designs is how template overfitting gets measured instead of assumed. |
| Same semantics, modern design | 100% | A third visual treatment of the same document. Three or more designs is the minimum for a layout-robustness claim that survives contact with a new vendor. |
| Liabilities of the issuing business | 100% | The businesses issuing these invoices also file a Schedule of Liabilities. Receivables on one side and debt on the other is the document set behind automated working-capital analysis. |
| Corporate return for the vendor | 100% | Vendor revenue flows to a corporate return. Tying invoice totals to reported receipts is the reconciliation both lenders and auditors run. |
Prevalence rates and category distributions above are corpus-derived: they were computed over the 641 employment-eligible identities inside a local synthetic corpus of 1,000 identities generated by SymageDocs' World Simulation Engine at seed 20260421 — the shipped definition gates this form on employment, so the remaining identities generate no invoice. Field, type and relation counts come from the shipped construction invoice definition in the SymageDocs form library. No real business, customer, or banking data was used at any stage.
Frequently asked questions
- What data format do synthetic construction invoices include?
- Each generated identity produces a rendered PDF plus a structured JSON annotation file with bounding boxes, field types, and ground-truth values for all 56 fields, plus 50 label-to-value relations. Fields are typed — 28 text, 18 currency, 7 number, 2 date and 1 employer identification number — and line-item fields record their row. COCO, YOLO, FUNSD, and BIO/NER exports come from the same job.
- How does this differ from the other invoice designs?
- Same commercial semantics, different visual design and a different field mix — this one carries the full remittance block with bank, routing and account details, a customer account number and a PO number. Running a model across the classic, modern, service, freelance and construction designs is how you separate real invoice understanding from template memorisation.
- How many line items does a typical invoice carry?
- Between three and seven. The first three lines appear on every invoice; occupancy falls to 79.1%, 56.8%, 38.7% and 18.6% for lines four through seven. The empty rows below the last populated line share the same ruled grid, which is where table extractors generate spurious rows.
- Are the bank details realistic?
- They are format-correct and internally consistent — a plausible bank name with a correctly shaped routing and account number — and entirely fictitious. No generated invoice points at a real financial institution's account. That combination is what makes the corpus usable for training payment-fraud detection without creating a payment-fraud liability.
- Can I use this data commercially?
- Yes. Every vendor, customer, amount and bank detail is synthetic, contains no real business or financial data, and is licensed for commercial use including model training, benchmarking, and redistribution inside your own products.