Most guides to writing an invoice list the legally required fields and stop. That gets you a document that is valid and still does not get paid on time.
So the question of how to write an invoice splits in two: the fields a tax authority requires, and the fields that decide whether it clears the client’s approval queue without anyone chasing it. The second set is shorter and does more work.
The required fields
These make the document a valid tax invoice. Details vary by country, but the core is consistent.
Your identity. Legal business name, address, company registration number, and VAT or tax registration number where you have one. Trading names are fine as long as the legal entity is identifiable.
The client’s identity. Legal name and address. For B2B in the EU, their VAT number, which is also what determines whether you charge tax at all.
A unique sequential number. Unbroken, from a series that only invoices use. The rules and the reason behind them are in invoice numbering.
Issue date, and the supply date if it differs. The supply date is what usually fixes the tax point.
A description of what was supplied. Specific enough that somebody who was not in the conversation can tell what they are paying for.
Amounts. Net per line, the tax rate applied, the tax amount, and the gross total. Where tax is not charged, the reason has to be stated: reverse charge, exemption, or below threshold.
The fields that actually get it paid
None of these are legally required. Each removes a common reason an invoice sits.
A due date, as a date. Not “Net 30”. A date needs no arithmetic and no interpretation, and it is what a reminder can point at. The term itself belongs in the signed agreement, where it can be cited if the date passes, and what the common terms mean is in net 30 payment terms.
Their purchase order or reference number. Many mid-size and large companies cannot pay an invoice without one. If you do not have it, ask before issuing, not after the due date. This single field is the most common reason an otherwise perfect invoice sits for a month.
The right recipient. The person you work with is usually not the person who pays. Ask at contract signature who receives invoices and send it there, with your contact in copy.
How to pay, completely. Bank details in full, including IBAN and BIC for cross-border, or a payment link. Every extra step you leave for the client is a day.
What it relates to. A project name, a contract reference, a period. Approvers reject what they cannot place.
Make the description match what they agreed to
The single most common cause of a disputed invoice is not an error in the amount. It is a description that no longer resembles what the client approved.
The proposal said “brand identity, including two rounds of revisions”. The invoice says “branding”. Six months later, in an argument about whether the third round was included, the invoice is the document with weight and it says almost nothing.
The fix is structural rather than a matter of being careful: the accepted document should supply the invoice lines rather than being retyped from memory. That is what a product catalog and proposals are for, and the four specific ways the two documents drift apart are in from accepted proposal to paid invoice.
Tax, and the part that is not about your country
The rate is not a property of your business. It depends on where the client is, whether they are registered, and what you sold.
For services inside the EU, a VAT-registered business customer in another member state usually means the reverse charge: you charge no VAT and state on the invoice that the reverse charge applies. Get this wrong in either direction and the invoice is not valid, which the client’s accountant will notice before their accounts payable does.
This is a property of the client, not of the document, which is why deciding it per invoice produces inconsistency. Resolving it from tax rules on the client record removes the most common silent error in cross-border work.
Sending it is not the last step
In much of the EU, emailing a PDF no longer counts as issuing an invoice. The invoice has to be transmitted as structured data through a network, with a deadline that runs from the issue date, which is what e-invoicing through ANAF and PEPPOL handles.
Two things follow for anyone writing an invoice by hand. The clock starts at issue, not at transmission, so a manual step between the two eats your own payment term. And an invoice that failed to transmit is not late in a way anybody notices until it is.
Before you send: a short check
- Does the number continue the sequence?
- Is there a due date, written as a date?
- Is their purchase order reference on it, if they use one?
- Does the description match what they accepted?
- Is the tax treatment right for their country and registration?
- Is it going to the person who pays?
Six questions, under a minute, and they prevent most of the reasons an invoice needs chasing at all. When one does go past its date anyway, the sequence that recovers it without damaging the relationship is in what to do when an invoice is not paid.
Where this sits in the wider chain
Writing the invoice is one step. Before it sits the agreement and the accepted scope; after it sit the payment and the receipt that proves it. The full path and the four places it leaks is the contract-to-cash workflow.
If the same invoice goes out every month, it should not be written at all. A billing schedule holds the arrangement and the invoice issues itself on the date you set. And knowing which ones were actually paid depends on matching payments to invoices.
Enlivy assembles the invoice from the record and sells the pieces as separate packs. You can start free.
If you are choosing between tools, the comparisons against FreshBooks, Wave and QuickBooks each say where they win.