Synthetic Form 940 Schedule R - Allocation Schedule for Aggregate Form 940 Filers Data
Synthetic training data — no real PII, fully coherent identities
Generate synthetic Form 940 Schedule R aggregate allocation schedules — 596 fields of multi-client FUTA payroll spread across a 15-row primary grid and a 22-row continuation page. A pure table-extraction workload with dollar and cent columns annotated separately.
596
Fields per document
3
Pages
Tax
Category
What this document is
Schedule R (Form 940) is the allocation schedule an aggregate FUTA filer attaches to its Form 940. A section 3504 agent or certified professional employer organization files one Form 940 covering many client employers, and Schedule R breaks that single return back out by client: one row per client EIN, with taxable FUTA wages, adjustments, credit reduction, total tax after adjustments, and deposits allocated to each. The primary page holds 15 client rows and the continuation page holds 22 more.
Why generate synthetically
This is a table, not a form. It is one of the very few IRS documents whose entire information content lives in a repeating grid, which makes it the ideal training and benchmarking target for table structure recognition, row segmentation, and column-aware extraction. Real Schedule Rs are impossible to share because every row names a client employer and its EIN — so labeled examples effectively do not exist in public datasets.
What makes synthetic data useful
Each row is a distinct simulated employer with its own EIN, state, and payroll, not a randomized number blob. The dollar and cent halves of every money column are generated as a matched pair, the per-client allocations correspond to the aggregate totals, and the subtotal cells reconcile against the rows above them. Filers carry a realistic number of clients rather than a full grid — a mean of 16 of the 37 available rows — so a document's populated rows stop partway down and the remainder are genuinely blank. That is the harder supervision signal: a model has to find where the table ends, not assume it runs to the last printed row.
Training challenges
Every money column on this form is physically split into a dollars cell and a cents cell separated by a printed divider, so a naive OCR pass returns twice as many numbers as there are amounts and a naive layout model merges neighboring rows' dollars with the wrong cents. Column headers appear once at the top of the grid and then govern 15 or 22 rows below, which puts the label 20 or more rows away from the value it describes — far outside the receptive field that key-value models are usually tuned for. The continuation page repeats the header block and the filer-type checkboxes verbatim, so page classification cannot distinguish page one from page two on appearance alone; only the row content differs. And because the two state-abbreviation cells sit between the client EIN and the first money column, row-order assumptions that work on financial tables break here.
Generate synthetic Form 940 Schedule R - Allocation Schedule for Aggregate Form 940 Filers data
Start with 500 free credits. No credit card required.
Generate NowWho uses this data
Certified professional employer organizations and section 3504 agents who file aggregate returns and have to reconcile them, payroll platforms that ingest client allocation schedules during onboarding or migration, and table-structure-recognition teams who need a hard, real-world grid to benchmark against instead of academic table corpora. If your extraction stack has never been tested on a split dollars/cents grid, this form will find the bug.
Document complexity profile
596 fields across a 3-page document with 2 field-bearing pages: 420 currency cells, 174 text fields, and 2 checkbox targets. 598 annotation relations. There are no conditional or arithmetic bindings, but 438 function-call bindings at a maximum expression depth of 1 — one per generated grid cell — because each client row's allocation is derived from that client's simulated payroll rather than sampled independently. Row occupancy varies with the filer's client count, so the grid is partly blank on most documents and a model has to detect the end of the table rather than read to the last printed row.
Key stats from our synthetic corpus
Quantitative characteristics of the Form 940 Schedule R - Allocation Schedule for Aggregate Form 940 Filers documents our generator produces.
| Metric | Value | Detail |
|---|---|---|
| Client rows per document | 15 + 22 | The primary page carries 15 client allocation rows and the continuation page carries 22, for 37 rows in a fully populated document. Generated filers average 16 clients: 45% spill onto the continuation grid and 55% leave it entirely empty, while half of all documents leave rows blank on the primary page too. The corpus therefore supervises partially filled tables in both directions rather than only the full-grid case. |
| Section 3504 agent filers | 63% | 62.6% of synthetic Schedule R filers check the section 3504 agent box. This is the dominant aggregate-filer type and the checkbox state that gates how a downstream reviewer interprets the allocation. |
| CPEO filers | 19% | 19.3% check the certified professional employer organization box. The two filer-type checkboxes sit in the header block that repeats identically on the continuation page, making them a useful probe for whether a model is reading page two or just re-reading page one. |
| Grid row fill rate | 44% of rows | Every one of the 596 fields is annotated on every document, but only the rows a filer actually has clients for carry values — 16 of 37 on average. The header, subtotal and filer-identification fields are always populated; the client grid below them is not, so the corpus trains both dense row/column association and the end-of-table decision. |
| Population coverage | 64% | 641 of 1,000 simulated identities are employed with an employer and therefore eligible to anchor a Schedule R filing, so a 1,000-identity run produces roughly 640 documents. |
How this document co-occurs with others
Rates at which identities in our corpus that produce a Form 940 Schedule R - Allocation Schedule for Aggregate Form 940 Filers also produce other documents.
| Correlation | Rate | Detail |
|---|---|---|
| The aggregate return it attaches to | 100% | Schedule R is never filed alone. Every synthetic Schedule R filer also produces a Form 940, and the allocated client wages correspond to the aggregate return's totals — the canonical attachment-reconciliation training pair. |
| Quarterly sibling schedule | 100% | The same aggregate filers submit Schedule R for Form 941 each quarter. The two schedules share a grid concept but differ in column count and row height, which makes them an excellent pair for testing whether a table model generalizes across layouts or memorized one. |
| State credit verification | 100% | The state unemployment contributions allocated on Schedule R are the same figures a Form 940-B verification request asks a state agency to confirm, giving you a grid document and a correspondence document over one underlying payroll. |
Stats above are corpus-derived: they were computed on a local synthetic corpus of 1,000 generated identities produced by SymageDocs' World Simulation Engine. The row-occupancy figures are the exception — they are read off the client-count distribution in the shipped Schedule R generator rather than sampled, so they are exact rather than estimated. No real employer, client EIN, or payroll data was used. `make corpus-stats` regenerates the shipped corpus_stats.json for the site's analytics form set, which does not include this edition; reproduce these figures with `python -m symagedocs.corpus_analysis --corpus-size 1000 --form-id irs_f940_schedule_r_standard_2024`.
Frequently asked questions
- What data format do synthetic Form 940 Schedule R documents 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 596 fields, with each dollar cell and each cent cell annotated separately and each row carrying its own index. COCO, YOLO, FUNSD, and BIO/NER exports come from the same job.
- What columns does each client row contain?
- Client EIN, two state abbreviation cells, a wage/tips/compensation type indicator, and five money columns — total taxable FUTA wages, total adjustments to FUTA tax, credit reduction amount, total FUTA tax after adjustments, and total FUTA tax deposited. Each money column is split into a dollars field and a cents field, giving 14 annotated cells per client row.
- How does labeling work for a table this wide?
- Field ids encode the row index, so total_taxable_FUTA_wages_dol_03 is unambiguously the fourth row's dollars cell. Continuation-page rows use a separate cont_ prefix. That lets you evaluate row assignment and column assignment as separate metrics instead of collapsing the whole grid into one flat key-value score, which is how most table extraction benchmarks hide their failures.
- Can I use this data commercially?
- Yes. All rows are synthetic client employers generated from statistical models, contain no real EINs or payroll data, and are licensed for commercial use including model training, benchmarking, and redistribution inside your own products.
- Do the allocations tie back to a Form 940?
- Yes. Generate Schedule R alongside Form 940 for the same identity set and the allocated client wages correspond to the aggregate return, which is exactly the reconciliation an IRS reviewer or an internal CPEO audit performs.