The Invoice Checklist to Run Before You Hit Send

A 30-day invoice that pays on day 55 usually didn't stall on the client's cash. It stalled on a missing PO number, a billing entity that doesn't match the client's system, or an amount that needs a correction the client couldn't make themselves. Every one of those is catchable in the two minutes before you send.

Run the same check on every invoice. Group the fields by how hard they are to change later. Some are locked the moment you issue. Some your client can edit on their own. Some need a formal request. Knowing which is which tells you where a mistake will cost you a full new version and where it won't.

The fields you cannot change once the invoice is issued

These lock on issue. If any of them is wrong, you are reissuing, so check them hardest.

• Invoice number. It has to be unique and it has to fit your sequence. If your last invoice was 2024-0117, this one is 2024-0118, not a random string. Gaps and duplicates are the first thing an auditor flags. Decide your format once with a fixed invoice number format so you never hand-type it.
• Issue date. This drives your payment terms. Net 30 counts from here, not from the day AP opens the email. Post-dating to buy the client time only delays your own due date.
• Sender details. Your legal business name, address, and tax ID (EIN, VAT number, or ABN as it applies). If the client's system has you on file under a slightly different name, match theirs, because AP matches invoice to vendor record before they pay.
• Bank details. Account number and routing, or IBAN and BIC for cross-border. One transposed digit means the payment bounces or lands somewhere else. Paste from a trusted source, don't retype. If you invoice abroad, an IBAN validator catches a bad string before the client ever sees it.

Because these lock, the cleaner move is to draft, review, and only then issue. A draft you can fix silently. An issued invoice with a wrong bank number is a credit note and a fresh send.

The fields your client can fix without asking you

Four fields are the client's own data, and they know it better than you do. Let them edit these directly. You get notified, and you can revert if something looks off. This is the core of letting the recipient edit their own invoice, and it removes the most common back-and-forth.

• PO number. Many AP teams will not pay without one, and they often issue it after you've already sent. Rather than reissuing, the client drops it in themselves. If you're unsure whether their PO string looks valid, the PO number format checker saves a rejection.
• Billing entity. The client may want the invoice addressed to a parent company or a specific subsidiary. Getting this wrong is a top reason AP kicks an invoice back.
• Billing address. Their registered address for tax, which is not always where you send the work.
• AP contact. The name and email of the person who actually approves. Once it's set, the invoice can be forwarded straight into their queue.

You don't have to know any of these perfectly at send time. Fill in your best guess, and let the client correct their own record. These edits are tracked amendments to the current version, not a new version, so your numbering and dates stay clean.

The fields that need a request, not a direct edit

Anything that changes the money is different. A client can't quietly rewrite your prices. They submit a change request, you approve or decline, and an approved change creates a new version (V1 to V2). That paper trail is the point.

• Line items. Descriptions and quantities. A vague line like "consulting" invites a hold. "Discovery workshop, 6 hours at 150" does not.
• Pricing and discounts. The rates and any reduction you agreed to.
• Currency. Match what the client expects to pay in. A euro invoice to a client who budgets in dollars adds a conversion argument.
• Payment terms and due date. Spell out what your net terms mean in plain words: "Net 30, due 14 August 2024." Don't make AP calculate the date.

Before you send, read your own line items as if you were the person approving them. If a description would make you ask a question, rewrite it now.

Two checks after the fields are right

Confirm the total. Subtotal, tax, and grand total should add up, and the tax rate should match the client's jurisdiction. Then confirm the terms are stated as a date, not just a term name.

Last, send it as a link, not a static file. A PDF that's wrong is a new email thread; a live invoice lets the client add their PO and fix their entity without waiting on you. If you want the full version to keep at your desk, work through the invoice before sending checklist once, then it becomes muscle memory.

Ready to put it to work? Create an invoice, run these three groups top to bottom, and issue only once every locked field is correct.