Guide
Responsible Use of Sample Documents
Sample documents are useful when everyone agrees they are samples. Problems start when fictional slips are treated as evidence. This page outlines responsible habits for designers, developers, trainers, and anyone using ReceiptPlay.
Legitimate uses
- UI/UX mockups and design critiques
- Software testing and QA fixtures
- Classroom or workshop practice
- Product demos with clearly fictional data
- Internal prototypes and pitch decks labeled as mockups
Sample documents vs actual business records
Business records come from real transactions and institutional systems of record. Sample documents come from a generator you control. Keep them in separate folders, tickets, and language (“fixture”, “mock”, “sample”).
Do not represent fiction as genuine evidence
Do not submit generated files as proof of purchase, reimbursement support, tax filings, or court evidence. ReceiptPlay does not authenticate payments. Brand-like layouts are illustrative only.
Testing environments and demo data
Prefer staging environments for upload tests. Seed demos with obviously fake names. If stakeholders might confuse a slide with a real slip, add a spoken or written “sample mockup” note.
User responsibility
You choose what to type, download, and share. Follow your employer’s policies and applicable law. When unsure, do not use a generated file for that purpose. Formal wording lives in the Terms of Use and Disclaimer.
Practical checklist
- Label shared folders as sample/test
- Use synthetic personal data
- Avoid mixing with finance archives
- Tell demo audiences the files are mockups
- Read Terms and Disclaimer when distributing widely
Responsible handling day to day
Store samples in clearly named test folders. When emailing a ZIP, state in the message that files are fictional mockups from ReceiptPlay. If you embed a slip in a pitch deck, a tiny caption (“Sample mockup — not a real transaction”) prevents awkward follow-ups from finance stakeholders.
Trainers should tell classes not to reuse classroom files in real expense tools. Developers should block production upload APIs from accepting fixtures flagged as sample when that control exists in their own systems.
What “responsible” looks like in demos
- Speak aloud that the document is generated for illustration.
- Use demo merchant names rather than a competitor’s live legal entity when that might confuse viewers.
- Avoid projecting QR codes that look payable without explaining they are invalid demos (ReceiptPlay’s postpaid QR codes are intentionally corrupted for this reason).
Boundaries with legal and policy pages
This guide is practical ethics for makers. Binding rules are in Terms of Use (permitted and prohibited use) and the Disclaimer (sample nature, no proof of payment). Privacy habits are covered in Privacy & Online Document Tools and the Privacy Policy.
Example — safe stakeholder review
Before a design critique, generate a rent receipt and a fuel slip with obviously fake parties (“Demo Landlord”, “Test Driver”). Export PNG, drop into the Figma frame, and title the frame “Sample documents for layout review.” Reviewers debate spacing instead of questioning whether someone actually paid rent.