Format spec
58 mm compact thermal receipt template
What a handheld reader or a phone-attached printer produces — the same conventions squeezed into 32 characters.
This is a generic industry format — the printing convention, not any company’s trade dress. You supply your own business identity; Get Receipt supplies the grid it prints on.
Physical spec
- Paper
- 58 mm thermal roll
- Roll or sheet width
- 57.5 mm
- Printable width
- 48 mm
- Horizontal dots
- 384
- Head density
- 203 dpi (8 dots/mm)
- Characters per line
- 32 (ESC/POS Font A)
The character grid is the printer’s, not an approximation: at 203 dpi a Font A cell is 12 × 24 dots, so 384 dots of printable width is exactly 32 characters. Anything you render has to land on integer dot multiples or the edges blur.
Ordered field list
Top of the document to the bottom. This is the order a reader expects and the order a scanner, a bookkeeper or a returns desk looks for.
- 1.Business name
- 2.Phone or city, address usually dropped
- 3.Date and time
- 4.Transaction number
- 5.Item lines, price on its own right-flush line when the description is long
- 6.Subtotal, tax, total
- 7.Tender and masked card tail
- 8.Tip line where the reader supports it
- 9.Thank-you line
- 10.Optional QR
Alignment
Heavy use of full-width right-flush single values, because 32 columns cannot carry a long description and a price on the same line.
Tax convention
Exclusive, usually as a single combined line with the rate shown.
Tender
Card approval with the last four digits, or cash with change.
Machine-readable code
A QR, if any — and it must carry a short link. A long URL pushes the module count past what 48 mm of printable width can render legibly.
How to recognise it
- Narrow, squeezed layout
- No SKU column
- Wrapped item names
- Address block dropped
- QR large relative to the tape width
Get Receipt renders this as Market stall duplicate book
The carbon duplicate-book page a stallholder writes out by hand: ruled lines, cash tendered and change, trader signature. Every total is recomputed by the engine from the line items, so the printed lines always sum to the printed total — the one thing generated receipts most often get wrong.