What to put on an invoice

An invoice is read by someone who was not in the room when the work was agreed. Most of what belongs on one answers a question that person would otherwise have to email you about, and each unanswered question slows the payment down. The invoice generator offers a fixed set of fields; here is what the main ones are for.

Where a field feeds the arithmetic, this page shows what the engine does with it, on a fictional invoice from Ellis Design Studio to Marchetti Holdings Ltd. Every figure was computed when the page was built, by the same code that builds your PDF.

Who you are, and how to be paid

“From (you)” takes a name and a free-text block: the address you trade from, an email address or phone number someone actually monitors, and — if you are registered for a sales tax or VAT — your registration number. Worth checking: the name on the invoice should match the name on the account receiving the money. A payment to “Jordan Ellis” against an invoice from “Ellis Design Studio” can get held by whoever reconciles the two, silently.

Who the client is

“Bill to” works the same way, and the name matters. Businesses often trade under one name and are registered under another — a café operating as “Corner Roast” may be “Marchetti Holdings Ltd” on the register — and the registered name is generally the one the money is owed by, not the sign above the door. Billing the trading name invites an accounts department to return the document, and can muddy the record if the debt is ever argued about. Ask once, at the start. If the client uses purchase order numbers, put theirs in the details block or the notes; an invoice arriving without one where it is required tends to be filed rather than paid, and nobody tells you.

What the engine checks on the two party blocks

Very little, on purpose. The engine is permissive about the parties and strict about the money, because a missing address is an inconvenience and a wrong total is a dispute. Each party needs a name: leave the sender blank and the document is refused with “Enter who the document is from.”; leave the client blank and it is refused with “Enter who the document is for.”. The details block is optional and is carried onto the document as typed — on the example invoice the client block reads “Trading as Corner Roast — PO 4471”, which is where a purchase order reference lives. Left empty, the block is left off the document rather than printed as a blank: the example built with the client's details cleared carries a name and nothing under it. The block is free text, carried in the order you type it. Nothing in either block is validated, looked up or formatted: a tax number is printed as text, not checked.

A number that is unique to you

The document number is a handle: what you quote in a chasing email, what the client quotes on the payment. It needs to be unique across everything you have ever issued — a duplicate defeats the point — and short enough to type. Left blank, the field fills itself from the issue date, so two documents made the same day would share a number; type your own. This tool does not number documents sequentially across sessions — nothing is stored, so it cannot know what you sent last month. The sequence is yours to keep, in a spreadsheet or a folder of saved PDFs. Numbering schemes are worth reading first.

What the blank field produces, computed

Built with the number field empty, the example invoice dated 20 March 2027 is numbered INV-20270320, and a second blank invoice built the same day to a different client gets the identical INV-20270320, because the engine has never seen the first one; typed, “ EDS-2027-014 ” prints as EDS-2027-014, trimmed. That is the whole of what the engine does with this field — it does not increment, check for a duplicate, or remember a number once the tab is closed — and the per-type prefixes and the case for a scheme of your own are worked through in how to number invoices.

Two dates, not one

The document date is the date of issue; the second date field is the due date. They do different jobs — the issue date says when the charge was raised and starts the clock, the due date says where it stops. Write a calendar date rather than “Net 30” alone, because terms given in days make the reader do arithmetic from a date they may take to be the day it landed. Payment terms covers the common ones.

How the dates render, and what the engine refuses

Dates are printed with the month spelled out, so a reader in either date-order convention reads them the same way: the example invoice issued on the twentieth of March with a due date on the first of April prints 20 March 2027 and 1 April 2027, never 03/20 and 04/01. The due date is optional, but when present it has to be a real calendar day and cannot fall before the issue date. A due date of the twenty-seventh of February on that invoice is refused with “The second date cannot be before the document date.”, and an issue date of the thirtieth of February with “Choose a valid document date.”. The refusals call it “the second date”: the same field serves every document type, and the engine's own description of it is the date payment is due or, on a quote, the date the price is valid until. The engine does no further date arithmetic: it neither counts net days nor decides when a payment is late.

Lines the client can recognize

A slow payment often has no dispute behind it — just a line the approver cannot match to anything they remember agreeing to. “Consulting services” with a four-figure number beside it sits until someone finds time to ask; “Onboarding documentation, 14 pages, drafted and revised, March 3–17” leaves nothing to ask. The reference worth including is the one the client thinks in. Two hundred lines are available, but three a client understands beat thirty they have to reconstruct.

Quantity and unit price

The unit price is the price of one of whatever the description names — one hour, one item, one day. Quantities are held to four decimal places, so a billed 3.3333 hours does not drift. For a fixed fee, the quantity is 1 and the unit price is the whole fee. Each line is quantity × unit price rounded once to the cent, so the printed lines add up to the printed subtotal; the methodology page works through that, and through where discount and shipping sit relative to tax.

Three lines, computed

The example invoice carries three lines. Fourteen pages of onboarding documentation at $85.00 a page is $1,190.00. Editing billed at $95.00 an hour for 3.3333 hours is $316.66: the exact product runs past the cent, and the engine rounds it half away from zero once, where the line is printed. Three stickers at $0.13 each is $0.39.

A unit price with more than two decimals never reaches the engine from the form. Money fields take two decimal places, so a sticker price typed as 0.125 is refused with “Enter a valid unit price with at most 2 decimal places.”. The engine still carries a rule for a price that does arrive with a fraction of a cent — the methodology page shows it on a line of dowels — and it is the other rounding rule: the unit price is rounded to a printable $0.13 before multiplying, so three stickers at 0.125 would print as 3 × $0.13 = $0.39 — not $0.38, which is what the unrounded price gives and which a reader with a calculator could not reproduce from the printed figures.

The subtotal is the sum of those three rounded lines: $1,190.00 + $316.66 + $0.39 = $1,507.05. Added by hand from the printed amounts the lines come to $1,507.05, which is the same figure — the point of rounding at the line rather than at the end. A line also has to say what it is for and cannot carry a negative price: a blank description is refused with “Every line needs a description.” and a price below zero with “Unit price cannot be negative.”. The engine takes a reduction only through the discount field, never as a negative line. The line limit is enforced the same way; a document with one line too many is refused with “A document holds at most 200 lines.”.

Typing the figures

A parser sits between the keyboard and the engine, and it accepts the common ways of writing a number without guessing between them. Typing 1,200.00, 1.200,00 or 1,200 into a money field all produce $1,200.00, $1,200.00 and $1,200.00 respectively — the same amount three ways. A string the parser cannot settle is refused rather than guessed: 1,2,3 returns “Enter a valid amount without ambiguous separators.”. Rates may carry their percent sign, so 8.25% is read as 8.25%. Quantities take up to four decimal places: 3.3333 is held as 3.3333, while 3.33333 is refused with “Enter a valid quantity with at most 4 decimal places.”.

Tax, if you charge it

Tax has three settings: “no tax”, “added on top”, or “already included”. The choice should match how you quoted the price. Quoted 1,200 plus tax, it is added on top; quoted 1,200 all in, it is already included, and the tax is extracted by dividing by one plus the rate rather than subtracting a percentage, which overstates the tax. The tax label is a separate field because the name varies; the one your customer will recognize is the right one. The rate you type is the rate applied — the tool does not look rates up or decide whether a sale is taxable. Sales tax and VAT explains the difference.

The 1,200 example, both ways

A fixed fee of $1,200.00 for a set of brand guidelines at an example rate of 20% carries tax of $240.00 and a total of $1,440.00 when set to “added on top”; set to “already included”, the $1,200.00 stays the total and the engine finds a net of $1,000.00 and tax of $200.00 inside it by dividing by 1.20, not by taking 20% of the gross, which would give $240.00 and overstate the included tax by $40.00. Enter tax-inclusive prices with the mode left on “added on top” and the engine adds tax a second time, faithfully, which is why the mode is the setting to check twice.

The label field is cosmetic and the mode is not. Leave the label blank and the engine supplies one from the mode — “VAT (included)” when prices already include the tax, “Tax” when it is added on top — and anything you type replaces it, trimmed, so “ GST ” prints as “GST”. Tax and discount rates are accepted up to 100% and 100%; one point above is treated as a typo rather than a rate and refused with “The tax rate cannot exceed 100%.” or “The discount cannot exceed 100%.”. The arithmetic behind both modes, at several rates, is worked through in inclusive versus exclusive tax arithmetic.

Payment instructions

The notes field is where you say how to pay: the account or method you accept, the currency the figures are in, and the invoice number to quote as a reference. If you charge interest or a fee on late payment, state it here if it was agreed in advance; some places also grant a statutory right to late-payment interest, and which applies depends on where you are.

What the engine does with the notes field

The notes are carried onto the document as text, trimmed of surrounding spaces and otherwise untouched. A note typed on the example invoice as “ Bank transfer to Ellis Design Studio. Please quote EDS-2027-014 as the reference. ” prints as “Bank transfer to Ellis Design Studio. Please quote EDS-2027-014 as the reference.”; a note of nothing but spaces is left off the document rather than printed as a blank. The field is held to 600 characters, counted before trimming: a note of exactly 600 characters is accepted, and one character more is refused with “Notes are limited to 600 characters.”. Nothing in the note is interpreted. A due date written there is not read as the due date, a bank account is not checked, and “Net 30” is not turned into a date; the date fields and the Already paid field are where the engine acts on those figures.

Already paid, and what the bottom line is called

Where money has already arrived, the “Already paid” field records it, and it is the last step in the order of operations. On the example invoice with a 5% discount, tax of 8.25% added on top, $24.00 of shipping and $500.00 received as a deposit, the total comes to $1,573.82; the $500.00 comes off that total, and the figure printed under “Balance due” is $1,073.82. The document prints both figures, so the client sees what was credited, and a payment larger than the total — $2,000.00 against the same invoice — leaves a balance due of $0.00, never a negative amount. The steps between subtotal and total are walked line by line in how invoice totals are computed.

The label on that bottom line is set by the document type, not by you. The same lines built as a receipt end under “Amount paid” at the document total of $1,573.82, with the “Paid by” entry — “Bank transfer, ref 8891” here — kept only on receipts, and built as a quote under “Quote total”; why that one label carries the distinction is the subject of receipts, quotes and the bottom-line label.

Currency

The currency selector offers 10 labels — $, £, €, ¥, C$, A$, INR, R$, kr, CHF — and the one chosen is printed beside the figures. It is a label and nothing more: no conversion is performed, no exchange rate is applied, and every amount stays in the currency you typed it in. The selector does not change the arithmetic either; a line, a discount or a tax rate is computed identically under any of the 10 labels. Left alone, the example invoice is labelled with “$”. Multi-currency conversion is among the things the engine does not model, as the methodology page records; one label applies to the whole document.

What the generator does and does not do with these fields

It computes. Each line is quantity × unit price in whole cents, rounded once; the subtotal is the sum of those lines; the discount comes off before tax; tax is added to, or extracted from, the taxable base according to the mode; shipping is added after tax; the amount paid comes off the total; the balance due is floored at zero. That chain, on further fictional documents, is set out line by line in how invoice totals are computed.

It does not file anything, track whether an invoice was paid, chase anyone, apply per-jurisdiction tax rules, validate a tax number, convert currencies, or number documents sequentially across sessions. It stores nothing: close the tab and the document is gone, so download the PDF. It is a document generator, not an accounting system and not tax advice. The full list of what is modeled and what is deliberately left out is on the methodology page, and the other guides — on numbering, payment terms, the tax modes, and the three document types — are collected under guides.

Questions

What your jurisdiction may require

Everything above is general practice. Many countries also require specific items on a document that functions as a tax invoice — a registration number, a registered address, wording such as “tax invoice”, or a breakdown of tax by rate. What is required, and whether a simplified document is allowed, differs by country and sometimes by state or province. This site does not know where you are and does not give tax advice; the rules that apply are published by your own tax authority and repay one careful read. Whatever they are, the free-text blocks and the notes field are where they go.