Reverting a Recipient Edit Without Wrecking Your Invoice

A client opens your invoice, adds their PO number, corrects the billing entity from "Acme Inc" to "Acme Global Services Ltd", and forwards it to accounts payable. Then you glance at the change, decide it looks unfamiliar, and hit revert. You just deleted the exact details AP needs to pay you. The invoice that was one approval away from payment is now stuck, and the client has to redo work they already did.

This happens more than you would expect. The revert button is powerful, and power used without reading is how correct input gets lost. Recipient edits to the PO number, billing entity, billing address, and AP contact are tracked amendments you can undo in one click. That is a good thing. It is also a trap if you treat every incoming edit as a mistake to be swept away.

Reverting before you read what the client actually changed

The most common error is reflexive. A notification lands, you see "billing entity changed", and you assume the client got confused. So you revert to the value you originally typed. The problem: you typed the wrong legal entity in the first place, and the client just fixed it. Their AP system will only match a PO and pay against the exact registered name on file. Your "correction" reintroduces the mismatch that gets invoices rejected.

Read the amendment before you touch it. If a client changes "Northwind Design" to "Northwind Design LLC", that is almost never an error. It is the name their finance system expects. When a client says the details are wrong, the fix usually lives on their side, which is the whole reason letting your customers edit their own invoice exists. Assume the recipient knows their own billing setup better than you do, and confirm before reverting.

Treating a PO amendment as noise instead of the key to payment

A missing or wrong PO number is one of the quietest ways an invoice dies. Many AP teams will not pay without a matching PO, and they will not chase you for it either. The invoice simply sits. So when a client adds a PO number after you sent the invoice, that amendment is the thing standing between you and payment.

Reverting it, or overwriting it with a number you guessed at, breaks the match. If you are unsure whether the format looks right, run it through the PO number format checker rather than deleting the client's value. When a client adds a PO after sending, the correct move is almost always to keep what they entered, as covered in more detail on how to handle a PO number added after the invoice is sent. If you genuinely need to change it, talk to the client first so both sides agree on the number.

Confusing an amendment with a version and reverting the wrong thing

PO and billing edits are amendments to the current version. Line items, pricing, and payment terms changes create a new version (V1, V2, and so on). These behave differently, and mixing them up leads to reverting more than you meant to.

Say the client requested a discount, you approved it and it became V2, and separately they updated their AP contact. If you "revert to V1" thinking you are only undoing the discount, you may also strip the amendment context you wanted to keep. Know which is which before you act. The full version history with one-click revert shows every change as a distinct entry, so you can undo a single billing amendment without rolling back an approved pricing change. If the distinction still feels fuzzy, the difference between invoice versions and amendments is worth reading once.

Reverting after the client has already approved

Once a client approves an invoice version, it locks permanently. That is by design. If you revert a billing amendment on an invoice that is already approved and locked, you are not editing a live document, you are fighting a record that both sides agreed to. At best you create confusion. At worst you invalidate the PO match the client's AP team already logged against the approved version.

Check the status before you revert. Draft, Sent, Viewed, and Change Requested are safe to adjust. Approved and Locked are not, and a revert there means issuing a fresh document with a new invoice number, not quietly rewriting history.

Not telling the client you reverted their input

Even when a revert is correct, silence causes trouble. The client edited the invoice, saw their change stick, and moved on. If you quietly undo it, they will not know the version their AP team is looking at no longer matches what they submitted. Then AP flags a mismatch, the client blames your invoice, and you spend a day untangling it.

When you do revert something, say so. A one-line message ("I reverted the billing address back to the head office address per your contract, let me know if that is wrong") keeps everyone aligned. If a client keeps hitting billing mismatches, the root cause is usually explained in why an invoice shows the wrong billing details, and it is rarely the field you are tempted to revert.

The rule that avoids all of these

Before you revert any recipient edit, ask two questions: does the client know their billing setup better than I do here, and is this the thing AP needs to pay me? If the answer to either is yes, leave it and confirm with the client instead. Keep the edit, keep the payment path intact, and use revert for genuine errors only. When you set up your next invoice, build the sender fields correctly the first time from the create an invoice screen so there is less to revert later.