Which Invoice Fields Are Locked and Which Can Change

· 5 min read

You sent a clean invoice on the 3rd. On the 9th your client emails: wrong billing entity, they need a PO number, and the CFO wants Net 45 instead of Net 30. In a static PDF world that means three emails, a re-export, and a new attachment nobody trusts is the final one. On JupiterInvoice, some of those changes the client just makes, some they ask you to approve, and one or two they cannot touch at all. Here is exactly which is which.

What can my client edit directly without asking me?

Four fields are the recipient's to edit. When they change one, you get notified, and you can revert it in a click if it looks wrong:

  • PO number. The one that stops an invoice cold. If their AP team will not pay without a matching PO, they can drop it in themselves instead of waiting for you to reissue.
  • Billing entity. The legal name that actually goes on the invoice, which is often not the name of the person who hired you.
  • Billing address. The registered address AP checks against.
  • AP contact. Who should receive and process the invoice on their side.

These are the details you are most likely to get wrong on the first pass, because only the client knows them. Letting them fix it is the whole point of giving clients a way to edit their own invoice. No account, no login, just the private link you already shared. For a fuller look at why these four in particular, see what AP teams check field by field.

Why can't they just change the amount or the payment terms too?

Because money and terms are your side of the deal, not theirs. Anything that changes what you get paid or when goes through a request-and-approve step. The client submits the change, you approve or decline. These are the requestable fields:

  • Line items
  • Pricing
  • Discounts
  • Currency
  • Payment terms
  • Due date

So when the CFO asks for Net 45, your client submits that as a request. You see it, decide, and either accept or push back. Nothing on the invoice moves until you say so. If you want to understand the difference between Net 30 and Net 45 before you agree, the rundown on Net 30 terms is a good start. For handling a steady stream of these without losing track, read how to run a change request without the chaos.

Which fields are locked and can never change once I send?

A short list, and it is short on purpose. Once an invoice is issued, these are immutable:

  • Invoice number. Changing it after the fact breaks your books and any audit trail. Set your format once with a numbering scheme that increments forever.
  • Issue date. The date the invoice legally exists.
  • Sender details.
  • Bank details.

Bank details being locked matters more than it sounds. Invoice payment redirect fraud usually works by editing the account number on a document mid-flight. If the account can never change after issue, that attack has nowhere to land. If you genuinely need a different invoice number or bank account, you issue a new invoice rather than quietly rewriting the old one.

Does a client edit create a new version of the invoice?

It depends on what changed. This is the distinction people trip over.

A PO number, billing entity, billing address, or AP contact edit is tracked as an amendment to the current version. The invoice stays V1. The change is logged, but you are not sitting on a pile of near-identical versions because someone corrected a postcode.

A content change (line items, pricing, terms, and the rest of the requestable list) creates a new version: V1 becomes V2, V2 becomes V3. Every version is kept, so you can compare and revert. That is the practical split between versions and amendments, and it is why the full edit history stays readable instead of ballooning.

What happens to editing once the invoice is approved?

Approval is the end of the line. When your client approves an invoice version, it locks permanently. No more edits, no more requests, no more amendments. The invoice moves through Draft, Sent, Viewed, and possibly Change Requested, then to Approved and Locked. If a change is needed after that, you issue a fresh invoice or a credit note against it.

This is deliberate. An approved invoice is the thing AP pays against, and it should not shift under anyone's feet after they have signed off. If you want the mechanics of the whole progression, the six statuses are broken down here.

Can I stop a client from editing a field I care about?

You do not need to. The four editable fields are ones you almost always want the client to own, and every edit notifies you with a one-click revert. If they set a billing entity you do not recognise, you undo it and message them. You keep control without blocking the fix.

The same logic runs through quotes: a client accepts by typing their name, and a "valid until" date caps how long your pricing stands. Developers who want to wire any of this into their own systems can drive it through the JupiterInvoice API.

The fastest way to see where each field lands is to build one. Create an invoice, share the link, and watch what your client can and cannot touch.

Send an invoice your customer can actually respond to

JupiterInvoice lets recipients add PO numbers, update billing details, request changes, and approve for payment, all from a private link. No account needed on their side.

Create an invoice