Skip to content
The invoice printed the wrong bank account

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.

  1. Print it from the document screen. Note the bank account in the footer.
  2. Open the e-Invoice PDF for the same document — the one with the QR code.
  3. 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.

It was very nearly otherwise, and the disabled version tells you what the design would have been. The print service contains a block of code, commented out, that would have looked up a cashbook from the document’s branch and offered its account number to templates. Note what it keys on: the branch. Note also what it does when the branch has several — it takes the first one it finds, in no particular order. Whoever wrote it reached for the branch, not the company, and that is the same instinct the rest of this page is about.

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.

This is the version that costs you money, and it is silent. The invoice looks entirely correct to the person who raised it and entirely plausible to the customer who pays it. You find out when the receipt lands in the wrong company’s cashbook, which is typically days later, and the correction is an inter-company transfer plus a conversation.

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 producedWhich layout it usesDoes the branch default reach it?
The print button on the document screenThe branch’s default for that branch and document type; otherwise the tenant-wide default templateYes
A document e-mail sent through a message templateThe layout named on the message template’s own branch or company link; only then the branch defaultSecond 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 platformNever

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:

  1. Raise or open a document for each company in your group, at the branch each normally uses.
  2. Print each one and read the footer. The bank account belongs to the company named at the top.
  3. 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 doWhat to do instead
Looking for a bank-account field on the invoiceThere is none. The number is template or footer text
Fixing the footer on one branch and calling it doneThe row is per branch and per document type — fix every combination that prints it
Assuming the e-Invoice PDF was fixed tooIt is chosen by company and never reads the branch default. Fix it separately
Changing the settlement method to correct the printed accountThe settlement method decides where the receipt posts, not what was printed
Reprinting after a fix and assuming the customer’s copy matchesA 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 footerMove the details to the company e-Invoice layout, or give each company its own branch

Related documentation

Last updated on