The invoice printed the wrong bank account
A customer has paid, and the money has landed in the wrong company’s bank account. You look at the invoice they were sent and it is on your letterhead, in your company’s name, with somebody else’s account number at the bottom.
Nothing selected that account number. That is the surprising part, and it is the whole explanation: BigLedger does not hold a bank account for an invoice to print. The number came from text somebody typed once, on a template, and the rule that chose that template does not look at which company issued the document.
Ten minutes here and you will know where the number on your invoice comes from, why it can disagree with the company name printed two inches above it, and which of three places to correct.
Meet GadgetSphere
GadgetSphere Sdn Bhd is three legal entities: the retail company GS with 22 branches, the e-commerce company GSO, and the distribution company GSD that bills corporate clients. Each has its own bank accounts. Several branches do work for more than one of them — a corporate order picked, invoiced and delivered out of a retail branch is a GSD invoice raised at a GS address. That is an ordinary week, and it is exactly the arrangement this page is about.
The 30-second check
Print the same document twice, two different ways, and compare the bank accounts.
- Print it from the document screen. Note the bank account in the footer.
- Open the e-Invoice PDF for the same document — the one with the QR code.
- Compare.
If the two carry different bank accounts, you have proved the point without reading any further: the number is not a property of the invoice. Two rendering paths, two layouts, two pieces of typed text, same document.
And if the printed bank account belongs to a company that is not the one named on the invoice, do one more thing before you touch anything: read the branch on the document header. For the copy that comes out of the print button, that branch — not the company — is what chose the layout.
Where the number actually comes from
There are exactly two places a bank account can be sitting, and neither is a field on your invoice.
1. Inside the template file. A printable format is a JasperReports template that somebody built and uploaded. Bank details drawn into that template are static text: the same on every document the template renders, for ever, whoever issued it.
2. In the Header or Footer text on a branch’s default layout. When a branch is given a default printable format for a document type, that row carries two free-text fields — a header and a footer — and they are handed to the template as text. This is where most bank details live, because it is the only place a person can type them without opening JasperReports.
What BigLedger hands the template beyond that is a fixed list, and it contains no bank account. Sixty-one company and branch parameters are passed in: the company’s name, logo, registration number, website, e-mail, phone and address; the branch’s code, name, logo, e-mail, registration number, address and phone numbers; the from- and to-location codes, names and addresses; the tax and SST registration identifiers. That is the complete set. There is no account number in it, and no cashbook.
Why the company name and the bank account can disagree
Here is the mechanism in two sentences, and it is worth reading twice.
The company name on the page comes from the document’s company. The print service reads the company from the document header’s own company field and fills in COMPANY_NAME from it.
The header and footer text comes from the document’s branch. The lookup that fetches them selects one row by document type and branch — and there is no company in that query at all.
A document header carries its company and its branch as two independent columns, set separately. So a GSD invoice raised at a GS branch prints GadgetSphere Distribution Sdn Bhd at the top, from the company column, and the GS branch’s footer at the bottom, from the branch column, complete with the GS bank account. Neither half is malfunctioning. They were never asked the same question.
Three layouts, three rules, and only one of them is the branch
The other half of the confusion is that a single document is rendered by three different paths, and each picks its layout differently. Setting a branch default fixes one of them.
| What is produced | Which layout it uses | Does the branch default reach it? |
|---|---|---|
| The print button on the document screen | The branch’s default for that branch and document type; otherwise the tenant-wide default template | Yes |
| A document e-mail sent through a message template | The layout named on the message template’s own branch or company link; only then the branch default | Second in line |
| The e-Invoice PDF (the one carrying the QR code) | The company’s e-Invoice layout for that document type; if the company has none, a built-in template shipped with the platform | Never |
So the e-Invoice PDF is the one path that is chosen by company rather than branch — and it is the one your customer is most likely to file. If the e-Invoice PDF shows the right bank account and the printed copy shows the wrong one, that asymmetry is the table above, not a fault.
The built-in fallback is worth knowing about on its own: a company with no e-Invoice layout of its own gets a platform template that receives none of the company or branch parameters and carries no logo. If your e-Invoice PDF has suddenly gone plain, that is what you are looking at.
Where to correct it
In the order that does the least damage.
If the wrong account is in the Header or Footer text, that is the easy case. It is a text field on the branch’s default printable format row for that document type, and correcting it takes a minute. Correct it on every branch and document type combination that carries it — the row is per branch and per document type, so fixing the sales invoice at one branch leaves the credit note, the cash bill and the other 21 branches exactly as they were.
If the wrong account is drawn into the template, the template has to be changed and re-uploaded. That is a JasperReports job. Ask BigLedger support for the sample template for the document type rather than starting from a blank canvas.
If a branch legitimately raises documents for more than one company, neither of the above is enough on its own, because one branch has one default row per document type and it cannot say different things for different companies. The practical answers, in increasing order of effort: keep bank details off the branch footer entirely and put them on the company’s e-Invoice layout, which is chosen by company; or raise each company’s documents at a branch of its own; or accept that the footer carries a single shared line and say so on it.
Do not fix it by editing the finalised invoice. The document is not where the number lives, so there is nothing on it to edit — and a finalised invoice has its own rules about what can change at all. See I cannot edit a finalised invoice.
The other bank account on the same screen, and why it is not this one
There is a second place a bank account appears on a sales invoice, and readers reach for it first because it is the one they can see: the settlement method on the payment tab, which carries the cashbook the money is booked into.
That list is also scoped by branch — the methods offered are the ones linked to the document’s branch, and the default for each payment type comes from that branch’s own default settlement configuration.
It is a different thing and it has different consequences. The settlement method decides which cashbook your receipt posts to inside BigLedger. The footer decides where your customer sends the money. They can disagree, they are configured in different screens, and only the second one is printed. Changing the settlement method on an invoice does not change a word of what was printed on it.
What you can and cannot undo
- The printed copy is gone. A PDF that has been e-mailed cannot be recalled. Correcting the template changes what prints next.
- Reprinting an old document uses today’s layout, not the one it was printed with. So a reprint after the fix looks right, and the copy your customer holds still does not. Do not let a clean reprint persuade you that nothing went out.
- Money that has landed in the wrong company’s account stays there until somebody moves it. That is a cash transfer between two legal entities, with two sets of books, and it is a finance job rather than a printing one.
- Nothing about this touches your ledger. The invoice posted correctly when it was finalised; only the paper was wrong.
What success looks like
Two minutes, on one document per company:
- Raise or open a document for each company in your group, at the branch each normally uses.
- Print each one and read the footer. The bank account belongs to the company named at the top.
- Open the e-Invoice PDF for the same three. The bank account is the same one, and the company layout is the one you set rather than the plain built-in template.
If all three agree on all three documents, you are done. If one company has no branches of its own, go back to Where to correct it — that is the case a branch footer cannot solve.
Common mistakes
| What people do | What to do instead |
|---|---|
| Looking for a bank-account field on the invoice | There is none. The number is template or footer text |
| Fixing the footer on one branch and calling it done | The row is per branch and per document type — fix every combination that prints it |
| Assuming the e-Invoice PDF was fixed too | It is chosen by company and never reads the branch default. Fix it separately |
| Changing the settlement method to correct the printed account | The settlement method decides where the receipt posts, not what was printed |
| Reprinting after a fix and assuming the customer’s copy matches | A reprint uses today’s layout. The copy they hold does not change |
| Letting one branch raise documents for several companies with bank details in its footer | Move the details to the company e-Invoice layout, or give each company its own branch |