How Do You Use Realistic Receipts in UI/UX Mockups?

Product teams need realistic receipts constantly: expense-app onboarding screens, POS system previews, banking-app transaction views, OCR test suites, demo environments that can't show real customer data. A good receipt mockup is structurally faithful (real anatomy, real math), safely fake (no real businesses, cards or people), and edge-case rich — because the crumpled, half-faded, 47-line grocery receipt is exactly what your product will meet in production.

Structural realism: get the anatomy right

Design against the real document, not a memory of one: header block, transaction metadata, item lines with the width-driven truncation thermal formats force, the subtotal/tax/total stack, payment block with masked digits, barcode footer (the full anatomy). Typography carries the realism: monospace, ALL-CAPS, 32 or 48 characters per line depending on 58/80mm width — a receipt mockup in a proportional font with generous kerning reads as fake to every user who's held the real thing. And the arithmetic must reconcile; designers are always caught by users who add things up.

Fast path: generate structurally correct receipts from templates — grocery, restaurant, gas formats each carry their dialect — then restyle in your design tool.

Safe fake data: the clearance layer

Same rules as prop receipts, enforced by policy rather than production legal: fictional merchant names (not real chains' names or trade dress), 555-01XX phones, invalid-but-plausible addresses, card numbers from the official test ranges (4242 4242 4242 4242 and friends — never a real BIN pattern with plausible remainder), and barcodes that don't resolve to real products. Demo data leaks — into screenshots, app stores, investor decks — so build fixtures as if they'll be public, because they will.

Edge cases: the fixture library your QA actually needs

A serious receipt fixture set includes: the 60-item grocery receipt (scroll and summarization behavior), the one-line coffee (minimal case), split payments and partial refunds, tips adjusting totals post-authorization, multi-rate tax receipts, VAT formats for international coverage, faded/skewed/crumpled photo variants for OCR pipelines, non-USD currencies and date formats, and handwritten receipts (the OCR-defeating case your error states must handle). Products designed on clean fixtures ship brittle; the edge cases are the spec.

Where teams use these

Onboarding and empty states ("snap your first receipt" needs a believable example), marketing screenshots (app-store rules and honesty both favor fake-but-realistic), sales demos (customer-shaped data, zero customer data), automated tests (OCR accuracy suites, rendering regression), and usability testing — where receipt realism directly affects task validity: users sort real-looking receipts differently than lorem-ipsum ones.

The line to respect

Mockup receipts are for fiction inside products — the moment a "mockup" is presented to a store, employer or insurer as a real transaction, it's fraud, and detection machinery treats it accordingly (how verification works). Same document, same tools — the use is the entire difference, as with receipt-making generally.

The bottom line

Faithful structure, honest math, cleared fake data, deliberately ugly edge cases. Build the fixture library once, and design, QA, demos and marketing all draw from it — realistic receipts, referencing nothing real.