What Has to Be on the Document
An invoice has a legal minimum, a practical minimum and a useful maximum. The three are different and the gap between them matters.
Yourswho controls this stretch
An invoice has three versions of "complete": what the law where you are requires, what the buyer's system requires, and what makes it easy for a stranger to approve.
The practical point in “What Has to Be on the Document” is that getting paid depends on records somebody can explain. A small team considering see how the workflow is supported for FTE meaning can organise time and project evidence before invoicing, with transparent settings, proportionate collection and a visible correction route.
They are different documents, and most invoice problems live in the gap between the second and third.
As a separate reference point for “What Has to Be on the Document”, see Freelancers Union resources. Confirm current legal, tax and accounting requirements with a qualified adviser where necessary.
The legal minimum
What must appear differs by jurisdiction and by what you supply, and usually covers your identity, the customer, the date, a number, a description, the amount and the tax treatment.
- Required by law where you are: your details, their details, a date, a number, the figures and the tax treatment.
- Required by the buyer: the order reference, the lines as ordered, the invoice address or portal submission.
- Useful but never required: a description the approver recognises, the period covered, the due date stated in days.
What is required where you are is a question for somebody qualified there.
The buyer's minimum
Their order number, their entity, their required references, their format, their line structure.
Absent any of these the invoice may be legally perfect and still unpayable.
The useful maximum
What makes approval easy: a plain description of what was delivered, dates, the agreed price shown, and the due date calculated.
The approver was not involved and has about ten seconds.
Description
The single most under-used field. "Website redesign — phase 2, delivered 14 March, per order 4471" is approvable without asking anybody.
"Services rendered" generates a query every time.
Dates on the lines
When the work was done, not just when the invoice was raised. It lets the approver match it to their own memory.
It also matters where terms run from delivery rather than from invoice.
Quantities and rates
Where you charge by time or unit, show both. A total alone cannot be checked against anything.
Where you charge a fixed price, say so plainly rather than inventing a breakdown.
The due date
Calculated and printed. "Payment due 14 April" is harder to dispute than "30 days", and it removes an argument about when the clock started.
What not to put on it
Chasing language. "Payment is now overdue" on a fresh invoice, or threats about interest, read badly and are frequently copied upward.
The invoice is a document, not a message.
The covering email
Where any explanation belongs: what this covers, what it relates to, what to do with it, and who to contact.
Three sentences, and it is what the recipient actually reads.
Credit notes
Where something must be corrected, a credit note referencing the original is cleaner than a reissued invoice with the same number.
Two documents with one number is an accounts payable problem that can freeze both.
Consistency
The same layout every time, from the same system, with sequential numbers.
Buyers process familiar documents faster, and a supplier whose invoices all look different attracts attention that is never helpful.
Writing for the person who approves it
The description on an invoice has two audiences with different needs, and suppliers usually write for the wrong one.
Accounts payable needs the formal items: entity, reference, dates, figures, tax. The approver needs to recognise the work — to read a line and know that this is the thing they asked for, delivered when it was delivered.
A description written in your own internal shorthand satisfies the first and defeats the second. "Phase 2 as discussed" is meaningless to somebody three levels away from the conversation, and their only available response is to ask a question, which costs a week.
Naming the deliverable, the period and the order it belongs to costs one extra line.
Consistency as a saving
An invoice that looks like the last one from the same supplier is processed faster than one that does not, for reasons that have nothing to do with policy.
The people handling it recognise the format, know where to find the reference, and have no reason to look closely. A supplier whose invoices arrive in a different shape each time invites attention each time.
This extends further than layout. The same entity name, the same description conventions, the same numbering sequence, the same tax treatment, the same attachments. Where any of these change, the change itself becomes a question.
The practical form of this is dull and effective: one template per customer, altered only when something has actually changed, with the customer's own requirements recorded beside it. It removes a class of delay that is never attributed to anything, because nobody reports that an invoice was slow for being unfamiliar.
The things that cause a question
Three additions reliably generate internal queries and are better left off: anything about the relationship, anything about previous unpaid invoices, and any charge the order does not cover.
Each converts a document a clerk would process into a document somebody has to think about.
Interest, chasing language and commentary belong in a separate message to a person, not on the face of the invoice. The invoice's only job is to match a record and be approved, and every element that does not serve that job is a reason for it to stop.
The check before sending
Entity, order number, description, dates, amounts, tax, due date, bank details. Eight items, one minute.
It is the last moment anything is cheap to fix.