Every Field Your Invoice Needs Before You Hit Send

A missing PO number can hold an otherwise correct invoice for three weeks. A wrong billing entity sends it back to you for a reissue. Most late payments do not come from clients who refuse to pay. They come from invoices that are incomplete or wrong in a way nobody flags until the due date has passed.

So before you send anything, walk the invoice field by field. The useful question is not just "is this field filled in" but "who is allowed to change it later, and what happens when they do." Get that right and you stop the back-and-forth that turns a 30-day invoice into a 55-day one.

The fields that must be correct and must never move

Some fields anchor the whole document. If they change after issue, your records and your client's records stop matching, and an auditor will notice. These stay fixed once the invoice goes out.

• Invoice number. One unique, sequential number per invoice. No gaps, no reuse. If you are still deciding on a format, read up on invoice numbering best practices before you send number one, because changing the scheme later is painful.
• Issue date. The date you raised it. Payment terms often count from here, so it drives the due date.
• Your details. Legal name, address, and tax registration where required (an EIN, a VAT number, an ABN, depending on where you operate).
• Bank details. Account name and number, sort code or routing number, IBAN and SWIFT/BIC for cross-border payment. A typo here is the one mistake that sends money to the wrong place.

In JupiterInvoice these are locked once the invoice is issued. The recipient can read them but cannot touch them, and neither can you without creating a fresh version. That is deliberate. The invoice number and your bank account are not things you want anyone editing quietly.

The fields the client should be able to fix themselves

Here is where most delays actually live. The parts of an invoice that are wrong are usually the parts that describe the buyer, not the seller. You do not know their exact registered entity. You do not know which PO their procurement team opened. You do not know who in accounts payable actually cuts the check.

Rather than guess and get it wrong, let the recipient correct those fields directly. In JupiterInvoice the recipient opens a link, no account needed, and can edit four things: the PO number, their billing entity, their billing address, and their AP contact. You get notified on every change and can revert anything that looks off. This is what letting your customers edit their own invoice is for.

Two of these deserve extra attention:

• PO number. If your client uses purchase orders, an invoice without a matching PO gets rejected by AP, full stop. If you are not sure whether you need one, the explanation of what a purchase order is covers when it matters. The common real scenario: you send the invoice, then the client realizes they forgot to give you the PO. Instead of reissuing, they add it themselves.
• Billing entity and address. "Acme Inc" and "Acme Holdings LLC" are different legal entities, and AP will bounce an invoice addressed to the wrong one. The person who opens your invoice usually knows the right answer. Let them set it.

These edits are tracked as amendments to the current version. They do not spin up a new V2, because nothing about the money changed. That keeps your version history clean.

The fields that change the money, and need your sign-off

Some fields you cannot let the client edit freely, because they change what you get paid. If a client could quietly drop your rate or extend the terms, the invoice would stop being a reliable record. But you also do not want to force a phone call every time they need an adjustment.

The middle path is a change request. The recipient asks, you approve or decline. In JupiterInvoice these requestable fields are line items, pricing, discounts, currency, payment terms, and the due date. When you approve a request, the invoice becomes a new version (V2, V3), and the old one is preserved so you can always see what the original said.

Each of these is worth a moment of thought before you send:

• Line items. Describe the work in the client's language, not yours. "Homepage redesign, 2 rounds" beats "Design work." Vague descriptions are the top reason AP asks questions.
• Payment terms and due date. Spell out the terms in words, not just a date. "Net 30" plus the actual due date leaves no room for interpretation. If you want the math done for you, the due date calculator handles it.
• Discounts and currency. If you offered an early-payment discount or you are billing in a currency the client did not expect, make it explicit on the face of the invoice.

Run the whole thing against a checklist before you send

Even knowing the categories, it is easy to skip a field when you are busy. The fastest safeguard is to check the finished invoice against a fixed list every time. Use the what to include on an invoice checklist as your last step before the link goes out. It covers the required fields for a standard business invoice, and it takes about a minute.

Two situations need a second look. If you are billing across borders, tax handling and bank details get more involved, and the practical guide to international invoicing walks through what to add. If your client uses a rigid AP process, check that your invoice would survive their approval flow before you send, not after they reject it.

Once your fields are sorted into locked, editable, and requestable, sending is the easy part. Create an invoice, share the link, and the client fixes their own details while you keep control of the numbers that matter.