A surprising share of "late payment" problems aren't about the client being slow -- they're about an invoice that got stuck in someone's accounts payable queue because it was missing a reference number, a due date, or a tax breakdown their system requires before it can even be entered. Getting the format right doesn't guarantee fast payment, but getting it wrong guarantees a delay.
The identifying details
Every invoice needs a unique invoice number and an issue date. The number matters more than people think -- it's how both sides reference the transaction later (in emails, in accounting software, in a dispute), and reusing or skipping numbers creates real bookkeeping confusion on your end, not just theirs. Alongside it: your business name and contact details, and the client's name and billing details, spelled exactly as they appear on their own paperwork so it matches whatever they file against.
The part people forget: payment terms
"Due on receipt" and "Net 30" produce very different payment behavior, and if you don't state terms explicitly, the client defaults to their own internal standard -- which is often slower than what you wanted. Put an explicit due date on the invoice, not just terms in prose, since some accounts payable systems ingest the due date field directly and ignore text elsewhere. If you charge for late payment, that has to be stated on the invoice itself (or in a contract it references) before the fact -- you generally can't add a penalty after the invoice is already out.
Line items, not a lump sum
A single "services rendered: $2,400" line is the single biggest cause of a paying company sitting on an invoice while someone internally asks what it's actually for. Break it into line items: what was delivered, the quantity or hours, the rate, and the line total. This isn't just about clarity -- some clients' finance departments are contractually required to match line items against a purchase order or contract before releasing payment, and a lump sum gives them nothing to match against.
Tax, subtotal, and total -- kept separate
Show the subtotal before tax, the tax rate and amount applied, and the final total, as separate lines rather than one combined number. This matters for the client's own bookkeeping (they may need to reclaim that tax) and for yours -- your revenue and your tax collected are two different figures and mixing them on the document makes reconciliation harder later, even if the math is correct.
The details that prevent a second email
Accepted payment methods and where to send payment (bank details, a payment link, whatever you actually use) should be on the invoice itself, not something the client has to ask for. The same goes for any reference number they gave you -- a PO number or project code -- since without it, some systems will bounce the invoice back before a human even reviews it.
None of this is about looking professional for its own sake -- every one of these fields exists because it's the specific thing that either lets an accounts payable process run automatically or forces a human to stop and go ask a question, and the question is where the delay comes from.
The Invoice Generator builds one with line items and tax handled for you, and exports straight to PDF.