Invoice Versions vs Amendments: The Practical Difference

You send invoice INV-2048 for 4,200 dollars on a Tuesday. Wednesday morning the client emails: "Can you add our PO number, BRT-9931, and change the bill-to from Acme Inc. to Acme Operations LLC?" You make both edits. Is that the same invoice, or a new one?

Under JupiterInvoice's model, both of those edits are amendments to the existing invoice. Nothing about the amount, the line items, or the terms changed. The PO number and billing entity are tracked edits on the current version. If the client had instead asked you to drop one line item and extend payment terms to Net 45, that would be a new version: INV-2048 V2, replacing V1, with its own approval step.

The plain definitions

A version is a new copy of the invoice created when the financial or contractual content changes. Line items, pricing, discounts, currency, payment terms, due date. Each version gets a label (V1, V2, V3) and needs its own approval. Once a version is approved, it locks permanently and cannot be edited again.

An amendment is a tracked edit to fields that don't change what the invoice charges or when it's due. PO number, billing entity, billing address, AP contact. Amendments stay on the current version. They are logged with a timestamp and who made the change, but they don't trigger a new version or a fresh approval cycle.

Some fields are neither. The invoice number, issue date, sender details, and bank details are locked from the moment the invoice is issued. You can't amend them and you can't change them in a new version. If one of those is wrong, you cancel and reissue.

Why the distinction exists

If every tiny edit produced a new version, your client's AP team would chase approvals all day. A PO number added on day three should not invalidate the approval workflow that started on day one. At the same time, if you quietly changed a unit price from 150 to 175 dollars on an already-approved invoice, that's not a small edit. That's a different deal. It needs to be a new version with a new approval.

The split maps to who actually cares about what. Procurement cares about PO numbers and bill-to entities, and they want to fix those without restarting anything. Finance cares about amounts and terms, and they want a fresh approval whenever those move. The complete version history of every invoice shows both: a clean list of V1, V2, V3 with their approvals, and underneath each version, the amendments stacked in order.

A worked example

Say you're a design studio and you send INV-2048 to a new client on June 3. Here's what happens over two weeks.

1. June 3, V1 sent. Three line items, 4,200 dollars total, Net 30, due July 3.
2. June 4, amendment. The client opens the link and adds PO number BRT-9931. You're notified. The invoice is still V1. No new approval needed.
3. June 4, amendment. The client updates the billing entity from "Acme Inc." to "Acme Operations LLC" and sets their AP contact to [email protected]. Still V1. You get notified and can revert if it looks wrong.
4. June 6, change request. The client requests removing line item 2 (a 600 dollar revision round) because it was already covered under retainer. You approve the request. The invoice becomes V2: 3,600 dollars, same Net 30 but recalculated due date.
5. June 6, amendment on V2. The PO number and billing entity carry forward. The client doesn't re-enter them.
6. June 7, V2 approved. The client clicks approve. V2 locks permanently. AP forwards it for payment.

If anything goes wrong after that, a credit note or a new invoice is the path forward, not editing V2. That's the point of locking.

What recipients can do without an account

The amendments above happen on the recipient side without anyone signing up. The client opens the private link, edits the PO field or billing entity directly, and you get notified. The same is true for letting your customer fix their own bill-to details. For changes that affect what they owe, they submit a request and you decide. The line between "edit directly" and "request a change" is exactly the line between amendment and version.

Why this matters for getting paid

Most invoice delays aren't disputes about price. They're missing or wrong fields that AP needs before they'll cut a check. A purchase order number that wasn't on the original invoice, a billing address that points at the wrong subsidiary, an AP contact you never had. If your tool forces a full reissue every time the client fixes one of those, you've added days to the cycle for no reason. Tracked amendments let the small stuff get fixed in place while the version history protects the financial record.

If you want to see this in action, create an invoice and share the link with yourself first. Edit the PO field as the recipient, then request a line-item change, and watch the difference between an amendment landing on V1 and V1 becoming V2. For teams building this into their own systems, the same model is exposed through the JupiterInvoice API and MCP server.