Guide

Organizing Sample Receipt Datasets

A pile of randomly named PNGs decays into noise. Organized sample datasets turn ReceiptPlay exports into assets your whole team can reuse. Treat them like code: naming rules, folders, indexes, and version notes.

Suggested folder structure

receipt-tests/
├── normal-cases/
├── long-text/
├── missing-fields/
├── high-values/
├── date-format-tests/
└── mobile-layout/

Keep a short README.md at the root stating that all files are fictional samples from ReceiptPlay and must not be used as payment proof.

Naming conventions

Include scenario intent, not only timestamps. Examples:

fuel_long-customer_v2.png
invoice_gst-two-items_shipping.pdf
mrp_2026-07_batch01.zip

Optional prefixes: test-case IDs from your tracker (TC-441_fuel_zero-litres.png).

CSV indexes and expected outcomes

Bulk generation can download a planning CSV alongside the ZIP. Store that CSV next to the archive and add columns your team cares about: expected OCR total, should_fail flag, viewport. Positive cases live under normal-cases/; negative or stress cases under long-text/ or high-values/.

Versioning

When templates change upstream, bump a dataset version (datasets/v3/) instead of silently overwriting baselines. Note the ReceiptPlay template name and approximate date in the README.

Batch generation with Monthly Receipt Plan

Monthly Receipt Plan builds a sample monthly set across a date range for demos and testing—not a live fuel history and not reimbursement planning. Use it when you need many dated slips for calendar UIs. Fixed count mode helps when you only need N files for a load test.

Keep synthetic data away from production

Never merge receipt-tests/ into production document stores. Use separate buckets, feature flags, or filename watermarks in your own system if needed. ReceiptPlay does not force watermarks on downloads; labeling is your process responsibility.

Scenario IDs and expected outcomes

Give every batch a scenario ID that appears in filenames, CSV rows, and your test management tool. Example: SCN-FUEL-MRP-Q3 means Fuel generator, Monthly Receipt Plan, third quarter sample set. Document the expected outcome next to the ID: “OCR extracts total within ±0.01”, “viewer shows three pages”, or “upload rejected because QR is invalid demo data.”

When a test fails, the scenario ID lets engineers regenerate the same ReceiptPlay inputs instead of guessing from a screenshot. Store a one-line “recipe” in the folder README: brand template, date range, monthly sample amount, and whether PNG or PDF was archived.

Positive vs negative cases

Positive cases prove the happy path—normal station lines, ordinary totals, complete optional fields. Negative and stress cases intentionally break assumptions: missing vehicle numbers, extremely long footers, dense ecommerce tables. Keep them in separate directories so automated suites can include or exclude stress packs without rewriting paths.

ReceiptPlay’s Fixed count mode is handy for negative packs (“exactly 25 ugly slips”). Monthly Receipt Plan is better when the product under test charts activity across calendar days. Neither mode creates real transactions; both only prepare demo datasets.

Working with ZIP and CSV together

After Generate sample batch, download the ZIP of slips and the planning CSV. Commit or artifact both. The CSV is your index: it can list planned dates and amounts even if a designer only glances at PNGs. If you re-export later, keep old ZIP names immutable and add _v2 rather than mutating CI baselines mid-sprint.

Example — building a mobile-layout pack

Create receipt-tests/mobile-layout/.
Generate three fuel slips with long station lines and one ecommerce PDF with two wide tax columns.
Name files mobile_fuel_01.png … and mobile_invoice_gst.pdf.
In your app, open each on a 375px-wide viewport and record wrap/overflow notes in a sibling notes.md.

This small ritual turns ad-hoc clicking into a dataset other teammates can clone.

Open Bulk / Monthly Receipt Plan →