I cannot edit a finalised invoice
You opened a sales invoice to fix something small — the wrong credit terms, the wrong salesperson, a date a day out — and every field on the header is grey. There is no message. Nothing tells you what happened or what to do instead.
What happened is that somebody pressed Final. Ten minutes here and you will know precisely what that froze, the three things it deliberately did not, why the person at the next desk may genuinely be able to do what you cannot, and the four honest ways to correct a document that has already posted.
Meet GadgetSphere
GadgetSphere Sdn Bhd runs 22 branches across three companies. A corporate invoice for RM 18,400 of ultraportable laptops went out this morning with the wrong salesperson on it and 30-day terms where the client is on 60. Neither error changes a cent of the accounting. Both matter — one to a commission run, the other to a collections call in four weeks.
The 30-second check
Look at the document’s posting status, then at which fields are grey.
- Every header field grey, including the transaction date — an ordinary final document, and you hold no permission that changes that. Go to The four ways to correct it.
- Everything grey except the transaction date — you hold the back-dating permission. Read The three deliberate exceptions before you use it.
- Everything grey except the Sales Agent — your tenant has the sales-agent setting on. That is the easy fix and it is below.
- Status is VOID or DISCARDED — the same lock applies for a different reason, and nothing on this page will reopen it.
- The fields are grey on a document that is still a draft — that is not this page. A draft can be locked for other reasons; ask whoever administers your tenant.
What Final actually freezes
Final is not a save. It is the moment the document becomes real: it takes a running number, posts its journal, moves stock, creates the receivable and hands the sale to everything downstream — e-invoicing, commission, loyalty points, the day’s takings.
From that moment fifteen header fields are locked together, as one decision:
Who and where — company, branch, location, delivery branch, delivery location. The commercial terms — credit terms, credit limit, due date, member card. The money’s shape — currency, both currency rates, and the two foreign-exchange source references. And the salesperson, which is the odd one out and is dealt with below.
The principle underneath is simpler than the list. Anything that decided how the document posted is frozen; anything purely descriptive may not be. The currency decided the amounts. The branch and company decided which set of books. The credit terms decided the due date, and the due date decides which aging bucket the invoice lands in next month. Letting any of them change under a posted journal would leave your ledger describing a document that no longer exists.
Why your colleague can do what you cannot
This is usually the question underneath, and the answer is not that somebody is wrong.
The lock is a policy decided per tenant and per person, not a property of the document. Two settings and one permission move the line, and all three are administered rather than earned:
- an applet setting applies to everybody on the tenant, and somebody with access to the gear menu can change it;
- a client-side permission applies to whoever holds it, so two people looking at the same invoice see different fields.
So “I could do this at my last company” and “she can do it and I can’t” are both usually true, and neither is a fault. The useful question to bring to your administrator is not “why is it locked” but “which of the three is off for me”.
The three deliberate exceptions
1. The sales agent
A setting exists that leaves the Sales Agent field editable on a final document. By default it is off and the field is locked with the rest of the header.
Why it exists at all. The sales agent is a reporting and commission tag rather than a posting value — nothing in the journal, the stock movement or the receivable depends on it. And the case for leaving it editable was made by customers: an invoice finalised with the wrong salesperson on it pays the wrong person’s commission, and the alternative to correcting it is voiding a perfectly good invoice and re-issuing it to a customer who has already received it. BigLedger’s ruling on a request to hard-lock it was to decline, on exactly that ground, and to make the change accountable instead of making it impossible.
What that means for you. If the field is grey and you need it, this is a request to your tenant administrator and a one-line change. If it is editable and you are worried about misuse, note the paragraph below on the record that is kept.
2. The transaction date
A client-side permission keeps the Transaction Date editable after Final. The code that implements it carries its own comment saying so: to allow back date even after final.
Treat this as the most consequential grant on the applet. The transaction date decides which accounting period an invoice belongs to. Moving it on a posted invoice moves revenue between months. There are legitimate uses — a document keyed on the 2nd that genuinely belongs to the 31st, corrected before anything closes — and there is no version of it that is routine.
3. Settlement adjustment
A setting reopens a Settlement Adjustment tab on documents that are already final, so settlement lines can be corrected afterwards: the customer paid by card and it was keyed as cash, the wrong cashbook, a cheque number typed wrong.
This one is the clearest illustration of the whole design, because the server’s rule runs the other way: a settlement change is refused when the document is not final. Settlement adjustment is something you are meant to do to a posted document. What it will not let you do is change the total — that is a hard rule at the server, and no setting reaches it. Correcting the total is a credit note, not an adjustment.
What is recorded when a final document does change
Worth knowing whichever side of this you are on.
Every successful change to a document writes an audit-trail row, carrying the operation, who did it, when, and both the record before and the record after. It is written by the platform on the update path, not by the screen, so it does not depend on which applet the change came through.
That is the accountability that makes the exceptions above safe to grant: the answer to “who changed the salesperson on this invoice” is a question with an answer, rather than a matter of trust.
The four ways to correct it
When the field you need is not one of the three, the document is not the thing you change. Pick by what is actually wrong.
| What is wrong | Use | What it does | What it costs |
|---|---|---|---|
| The amount, the price, the tax — anything the customer owes | Credit note | A separate document reducing what the customer owes, applied to the invoice | Nothing is hidden. Both documents stand, and the audit trail is clean. This is the normal answer |
| You under-billed | Debit note | The mirror of the above, increasing the balance | Same |
| Goods came back | Sales return | Reverses the sale and brings the stock back | The only one of the four that moves inventory. Do not use a credit note for returned goods |
| The whole document should never have existed | Void | Reverses the posting and leaves the document visible, marked void | Permanent and visible for ever. Your auditor will ask. Use it for a genuine mistake, not for tidiness |
Two smaller tools worth knowing, because each saves a void:
- Swap Serial Number replaces the serial number on a final invoice without voiding it — for when the right unit left the shop under the wrong serial.
- Settlement Adjustment, above, for how the money came in.
What you can and cannot undo
- Final cannot be undone. There is no un-finalise. An attempt to re-finalise a final document is refused outright, with a message saying it has already been posted.
- A void cannot be undone, and the voided document stays on the record.
- A credit note can be corrected with a debit note, or unapplied and re-applied elsewhere. Nothing is lost.
- A settlement adjustment can be adjusted again. The total cannot move.
- Changes made under the three exceptions are all recorded, so a change made in error is traceable rather than deniable.
What success looks like
Thirty seconds, before you decide anything:
- Name what is wrong in one sentence. If the sentence contains an amount, you want a credit or debit note. If it contains “goods”, you want a sales return. If it contains neither, you probably want a setting, a permission, or a change to the customer record.
- Check whether the field is one of the three exceptions. Two of them are a request to your administrator, not a workaround.
- If you have reached for Void, say out loud why the credit note is not enough. If you cannot, use the credit note.
Common mistakes
| What people do | What to do instead |
|---|---|
| Voiding a finalised invoice to fix a typo that moved no money | Fix the master data for next time; correct this one with the right instrument or not at all |
| Using a credit note for goods that physically came back | Use a sales return — it is the only one that moves stock |
| Asking for the whole document to be unlocked | Ask which of the two settings and one permission you need. The rest is locked for a reason |
| Treating an editable transaction date as an ordinary field | It moves revenue between accounting periods. Use it deliberately, or not at all |
| Correcting credit terms on the invoice | They live on the customer record. The invoice is a copy taken at the time |
| Assuming a post-final change is untraceable | Every update is recorded with who, when, before and after |