Why does an old invoice still show the old address? What a document keeps of the customer
A sales document copies the customer when the customer is picked, and keeps the copy. So a correction in Customer Maintenance reaches the next document, not the ones already raised. This page sets out what is copied and when, the values that are read live instead, and the e-invoice buyer that is copied later.
What a document keeps of the customer record
Somebody will ask you this the first time they correct a customer in Customer Maintenance and then open last year’s invoice: why does the old invoice still show the old details? Because that is what it is for.
When a customer is picked on a sales document, BigLedger copies a block of the customer record onto the document — customer code, name (with the contact’s name appended when a contact was picked), status, e-mail, phone, GL code, identity number and type, entity type, description and currency, plus the billing and shipping contact and the address chosen from the Address tab. The document does not point at the customer record and read through it. The server fills that block from the customer record only when it arrives empty, and never refreshes one that is already there.
So a correction in Customer Maintenance reaches the next document, not the ones already raised — and that is deliberate. An invoice is evidence of what was agreed; it has to keep the name and address it was raised against, or a reprint stops matching the copy the customer is holding.
| You change… | What happens to documents already raised |
|---|---|
| Name, address, e-mail, phone, identity number | Nothing. Each keeps the copy taken when it was raised |
| Credit term, credit limit, GL code | Nothing. Those are copied onto the document too |
| AR/AP type | The receivable account moves the next time the document posts — this one is read live, not copied (The AR/AP type is decided once) |
| E-Invoice tab: TIN, ID, SST number, the ticked address | Depends on whether the document carries a buyer of its own, and whether its e-invoice record has been built yet (next) |
| Merge the customer into another | The snapshots on documents already raised are rewritten with the surviving record’s details, the survivor’s own documents included; e-invoice records already built are not (Customer Maintenance → save, import or merge; Supplier → Entity merging) |
Two things follow for you. A clerk who corrects a customer’s details on one invoice has corrected that invoice, not the customer record — nobody is prompted to bring the correction back to the customer record, and it is worth asking for when you see an invoice that disagrees with the master. And when a report built from documents disagrees with Customer Maintenance, the documents are not stale data to clean up; they are the record of what was true at the time.
The same rule applies to suppliers and to every document-issuing applet.
The e-invoice buyer: read once, then frozen
The e-invoice is the one copy that is not taken when the document is raised. After FINAL, the e-invoice job builds an e-invoice record, the copy LHDN actually receives, and takes the buyer from the first of these that has one:
- the document’s own e-invoice buyer block (or, failing that, its general e-invoice block), which the storefront’s e-invoice request and the sales document imports, among others, can fill;
- otherwise the customer record as it is at that moment: Name, the E-Invoice tab’s TIN, ID type and value and SST number, the Main tab’s ID number, e-mail, phone, and the address ticked default e-invoice address (shipping, then billing, then main).
From then on the e-invoice record keeps its own copy. Correct the TIN in Customer Maintenance afterwards and the e-invoice already built keeps the old one, including after LHDN has rejected it: Save and Resubmit sends the record’s own buyer again and never reads the customer record. Fix a rejected buyer on the record’s Account tab in My E-Invoice Admin. When the wrong value came from the customer record itself, correct it on that customer’s E-Invoice tab as well, so the next sale is right; when the buyer is a different party from the customer you billed, leave the customer record alone. The record that goes to LHDN is not your invoice follows one record through.
Why the buyer is not simply the customer. The person you bill and the party LHDN should see as buyer
are not always the same. A shopper buys a laptop at GS-KV-03 and pays for it himself, so the cash bill and
the receivable are his; later he needs the e-invoice in his employer’s name to claim the cost back. BigLedger
lets the two differ, and lets the buyer be completed afterwards in My E-Invoice Admin by someone with time to
get it right, rather than at the till. An e-invoice whose buyer differs from the customer record is therefore not, by
itself, an error.
One job writes back. When a sales invoice or cash bill of RM 10,000 or more reaches the e-invoice job with a buyer whose ID type is a business registration number (BRN), an ID number and no TIN, the job asks LHDN for the TIN by that registration number. A TIN found is written onto the e-invoice record, onto the document’s buyer block if it has one, and onto the E-Invoice TIN of a customer record: the buyer the document’s e-invoice block names, or the document’s own customer when the block names none.
Related documentation
- Customer Maintenance — the record itself, its E-Invoice tab, and the AR/AP type, the one value a posting reads live.
- Supplier — the same copy rule on the purchase side, and what an entity merge rewrites.
- Duplicate customers — deciding that two records are one, before a merge rewrites every snapshot.
- My E-Invoice Admin — where one e-invoice’s buyer is completed or corrected without touching the customer.
- The generic document — the one record behind every document type that carries the copy.