A receipt is a short written record confirming that money has already been paid for goods or services, listing what was bought, what was charged, and what change was returned, and the most reliable way to make one is to capture the transaction immediately in a local tool that calculates every figure from the inputs you supply. The fastest path to a clean, itemized receipt is to enter the merchant name, payment date, receipt number, currency, and each line item with its quantity and unit price; add any flat discount, percentage tax, and tip; type the amount the customer actually handed over; then let the calculator produce the subtotal, tax, total, and change from those exact numbers. Because a receipt confirms a completed payment rather than requesting one, a good workflow refuses to print anything labeled paid when the cash tendered is less than the calculated total. The tool described in this guide, the Lizely Receipt Maker, follows that rule, runs every calculation locally in your browser, and lets you print the result or save it as a standalone HTML file you can reopen later.
What Every Receipt Needs to Include
Every usable receipt, regardless of who issues it, carries the same six categories of information so the document can still be read months later by a customer, a bookkeeper, or a tax authority. The header identifies the merchant, the payment date, and a unique receipt number that lets the document be retrieved from a ledger. The body lists each paid item or service as a separate line, with a quantity, a unit price, and the resulting line amount. The middle of the page shows the financial adjustments: any flat discount subtracted from the subtotal, the percentage tax applied to the discounted subtotal, and any flat tip. The footer carries the final total, the amount tendered by the customer, and the change returned. Filling in only a subset of those categories turns the page into a hand-written note instead of a receipt, which is why a tool that prompts for every category at once keeps the structure consistent across many transactions.
Why the Receipt Maker Solves the Problem
The challenge with hand-built receipts is that every figure has to be computed mentally, and a single arithmetic slip turns a paid receipt into a customer dispute. Floating-point calculators often display surprising tails: $0.10 plus $0.20 can read as $0.30000000000000004 because the underlying binary representation cannot represent those decimals exactly. A tool that performs all money math in integer minor units — converting $1.00 to 100 cents before adding — removes that class of error completely. The Receipt Maker applies that approach to the whole receipt, including each line item, where the unit price is multiplied by a validated quantity and rounded to the nearest minor unit only after the multiplication has been performed. Inputs that are blank, negative, non-numeric, or exceed the supported ranges are rejected rather than silently replaced with zero, so a stray keystroke cannot quietly invalidate the total. Combined with a generation guard that requires the amount tendered to equal or exceed the calculated total, the result is a receipt whose numbers match the cash that actually changed hands. To see this in practice, open the Receipt Maker in your browser; nothing leaves the device, so you can experiment freely with test data.
Build a Receipt in Three Stages
The whole workflow fits into three stages, each covering a coherent block of fields on the form. Stage one establishes who is being paid and when: the merchant name, the payment date, the receipt number, and the display currency used for the transaction. Stage two captures what was bought and how it was paid for: each line item with its quantity and unit price, then the flat discount, the percentage tax, the flat tip, and the amount tendered. Stage three is verification: read the preview carefully, confirm every total and the change shown, then print the receipt or save it as a standalone HTML file for the record. The full sequence is:
- Enter the merchant name, payment date, receipt number, and select the display currency used for the transaction.
- Add each paid item as a separate row with its quantity and unit price, then enter the flat discount, percentage tax, flat tip, and amount tendered.
- Generate the receipt, verify every line amount and the change shown in the preview, then print the page or download the standalone HTML file.
After any edit, the previous generated result is cleared automatically, so the next preview always reflects the latest entries and cannot be confused with output from earlier inputs. Each receipt supports up to 100 line items, and any value that fails validation is reported rather than replaced, so the underlying issue can be corrected before the receipt is generated. A flat discount cannot exceed the subtotal it would be subtracted from, and totals that exceed the supported amount range are flagged so the calculation can be reviewed.
How the Arithmetic Stays Exact
The Receipt Maker avoids floating-point tails by converting every two-decimal monetary input to integer minor units before any addition or subtraction. For a currency shown with two decimal places, one major unit becomes 100 minor units, so $0.10 becomes 10, $0.20 becomes 20, and 10 plus 20 returns exactly 30 minor units, which the renderer formats back as $0.30. Unit prices accept at most two decimal places, quantities accept up to three, and a line amount is rounded to the nearest minor unit only after the validated quantity multiplies the integer unit price. The calculation order is explicit and matches the rules shown in the preview:
| Step | Action | Resulting value |
|---|---|---|
| 1 | Add every validated line amount | Subtotal |
| 2 | Subtract flat discount (cannot exceed subtotal) | Discounted subtotal |
| 3 | Apply tax percentage to discounted subtotal, rounded to nearest minor unit | Tax amount |
| 4 | Add flat tip | Total |
| 5 | Compare amount tendered with total | Change = tendered − total, or generation stops |
A worked example shows the order end to end. Two items are purchased: 1 × $12.50 and 3 × $4.00. The line amounts are $12.50 and $12.00, so the subtotal is $24.50. A $2.00 discount brings the discounted subtotal to $22.50. An 8 percent tax on $22.50 produces $1.80 exactly, because $22.50 × 0.08 = $1.80 with no rounding needed. A $3.00 tip brings the total to $27.30, computed as $22.50 + $1.80 + $3.00. If the customer hands over $30.00, the change is $2.70, computed as $30.00 − $27.30. Generation succeeds; if instead only $25.00 had been tendered, generation would stop and no paid receipt would be produced.
Receipt vs Invoice: The Functional Difference
The biggest source of confusion around this kind of document is the difference between a receipt and an invoice. An invoice asks a customer to pay: it carries a due date, lists the amount owed, and may be issued before any money has moved. A receipt confirms a payment that has already happened, names the amount tendered, and shows any change returned. Mixing the two turns a polite payment request into a misleading paid record, which is exactly the failure mode the Receipt Maker is designed to prevent. The functional split is summarised below:
| Aspect | Receipt | Invoice |
|---|---|---|
| Purpose | Confirms a completed payment | Requests a payment from a customer |
| Generation guard | Refuses to print if tendered amount is below total | Generates for any requested amount, including future due dates |
| Required fields | Amount tendered, change due | Due date, balance owed |
| Typical next step | Customer keeps the document for their records | Customer arranges payment by the due date |
| Right tool for this task | Receipt Maker (this guide) | Invoice Generator |
If you need to record a partial payment, set a due date, or show an outstanding balance, use the Invoice Generator or a bookkeeping system that supports payment allocation and an audit trail; the Receipt Maker is intentionally scoped to one completed payment and does not maintain customer accounts, sequential ledgers, inventory, refunds, voids, or payment processor records.
Local Processing and the Privacy Boundary
Every calculation, every preview render, every printed page, and every downloaded HTML file is produced inside the current browser. The merchant name, line items, prices, notes, tax rate, tip, and any payment figures stay on the device; no values are uploaded to Lizely as you type or generate. That local-only design has two practical consequences. First, you can use the tool on a shop laptop without worrying that customer data is being transmitted to a third-party service. Second, because a downloaded or printed HTML page can be edited by anyone who opens it later, it cannot be treated as independent proof against fraud. The authoritative payment evidence — the payment processor record, the cash register journal, the bank entry, or the signed agreement — should still be retained alongside any printed receipt.
Print or Save the Finished Receipt
Once every total in the preview looks right, two output paths are available. The Print receipt action opens the browser print dialog, where the page can be sent to a paper printer or, if the operating system provides that option, saved as a PDF. That dialog is the same interface described in the MDN Window.print reference, so the experience is consistent across modern browsers. The Download HTML action saves a standalone file containing the validated values visible in the preview, plus a compliance disclaimer, in a format any ordinary browser can reopen and print later. Because the file is just HTML, it can be archived alongside other bookkeeping documents without needing the original tool to reopen it, and it uses the same Blob-based download approach documented in the MDN Blob reference.
What the Tool Will Not Replace
It is worth being explicit about what the Receipt Maker does not do, because the limits are part of what makes the result trustworthy. The tool does not contain tax tables, product exemptions, jurisdiction-specific rounding mandates, sequential ledger numbering rules, or any authentication of the merchant or the payment. It does not create a tamper-evident signature, a fiscal receipt, or an archived compliance record, and it does not integrate with a payment processor, a cash register, or a point-of-sale system. Treat the produced page as a readable convenience document for one completed payment; keep the payment processor statement, the signed agreement, or the cash register journal as the authoritative evidence for any dispute, reimbursement, warranty, insurance, or regulated recordkeeping need, and consult a qualified professional when a receipt must meet a specific legal or tax standard.
Related reading: How to Make Receipts for Your Small Business.
Related reading: Make a Receipt Book Online With Numbered Records.