The invoice is FINAL but it is not in the ledger

“The invoice is FINAL, but it is not in the ledger.” The document reads FINAL and looks normal on the listing, yet there is no journal behind it, so the trial balance and the receivable account never moved. A document that is FINAL with no journal, where your business posts its ledger in BigLedger, is a posting that did not complete or did not start, and the fix is to repair the cause and then post the journal. This page is for whoever owns the chart of accounts or closes the month. It covers sales invoices first; the same applies to a cash bill, a credit or debit note, a return and a purchase invoice.

The fast path.

1. Check the document type. A quotation, a sales order or a delivery order posts no journal at all, so for those nothing is missing (what posts and what does not).
2. Open the invoice’s Posting tab. Journal Posting Status reads POSTED on a posted invoice. Empty means the posting failed or has not run yet; if you finalised it seconds ago, refresh first.
3. Before you press anything, check two things. If the invoice came from an integration, or your business keeps its ledger in another system, read the integration and other-ledger cases under What Resolve tells you first: a journal may not be wanted. Ask whoever keys manual journals whether one was linked to this document through Server Doc No: posting a document removes every journal linked to it first, even when the posting then fails. And the journal lands in the invoice’s own month, even a locked or reported one.
4. In Financial Report › Error Checking › Trace Document, give it the document type and number, and press Resolve on Missing Journal. It posts the journal or shows why it cannot; if nothing on the check changes, the journal did not save. Fix the reason (What Resolve tells you), then press Resolve again.
5. For a whole month, use Missing Journal in Ledger And Journal (Fix the cause, then post the journal, step 3).

Meet GadgetSphere

GadgetSphere Distribution Sdn Bhd (GSD), the group’s wholesale company, raises its first corporate invoice: RM 5,000 of ultraportable laptops plus RM 300 SST, RM 5,300 in all. The clerk presses FINAL, the invoice is numbered, and the customer gets the PDF. At month end the trial balance for GSD shows no sales at all. The retail company GS was set up months ago; GSD’s default GL codes were never finished.

Why FINAL does not put it in the ledger by itself

Finalising does not post. It asks for the posting. When you press FINAL, BigLedger checks the document, saves its status and number, and then queues a job that builds the journal (along with the stock movement and the other follow-on work). The screen returns as soon as the status is saved. The journal is built from the company’s default GL codes a moment later.

If that job fails, the document stays FINAL with no journal, and nobody is told. The failure is written to a job error log, and the person who finalised it saw an ordinary FINAL. That split is deliberate: the clerk at the desk finishes the sale, and the person who owns the chart of accounts repairs the mapping. It also means somebody has to look: Who looks for these, and when.

What Resolve tells you, and what each message means

Press Resolve on Trace Document’s Missing Journal check and the check shows the server’s message. Missing Journal’s Create shows only the code in its Remarks column: MISSING_DEFAULT_GL_CODE without the account, COMPANY_DEFAULT_GL_CODE_NOT_EXIST or TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES. Match it here:

An invoice created already FINAL by an integration is given its number and handed to e-invoicing (a failure of either is only logged), but no journal or stock job starts from it. Resolve builds its journal; it does not move its stock. Find out how the document arrived first (Sales that arrive from another system, Step 2).

Some businesses keep their general ledger in another system, and have BigLedger post no journal for any invoice, whoever raised it. If every invoice is on the Missing Journal list, ask your administrator whether yours is one of them before you post a month of journals into it.

Three look-alikes that belong to another page

• A journal exists but is short. An unmapped SALES or OUTPUT_TAX code fails nothing: the line it cannot place is left out and the customer’s line absorbs it, so Trace Document finds nothing wrong (A journal that left a line out).
• MISSING_CASHBOOK or MISSING_GL_CODE on a receipt, payment or cash transfer. A settlement method has no cashbook, or its cashbook has no GL code (Stuck documents and missing records).
• FINAL was refused. Then the document is not FINAL at all; the message names the reason (Refusals at Finalise).

Fix the cause, then post the journal

1. Repair the cause from the table, for the company the invoice belongs to. In a group of companies, the gap is usually in the second or third company, where nobody finished the setup.
2. For one invoice: Financial Report › Error Checking › Trace Document, the document type and number, then Resolve on Missing Journal. The check reads Manually resolved when the journal is saved; if nothing on the check changes, the journal did not save.
3. For many: Ledger And Journal › Error Checking › Missing Journal. Pick the document type (one per search) and set both dates to the month you are repairing, because both open on today. Search, select one row first, press Create and read its Remarks; fix what it names before you create the rest. Each row’s Remarks reads SUCCEED, or an error code that names the reason. A blank row means the rebuild did not save: fix the cause and press Create again (Ledger And Journal › Error Checking).

A foreign-currency document is not posted this way. Trace Document marks its checks Not applicable for Forex Document and offers no Resolve, and Missing Journal’s Create is refused for it. Take that one to your BigLedger contact with the document type and number.

What success looks like

• The invoice’s Posting tab reads POSTED.
• Trace Document’s Missing Journal check reads Posting journal present.
• Missing Journal for that document type and month comes back empty.
• The journal itself has one debit to trade debtors for the invoice total, RM 5,300 in GSD’s case, and credits to sales and SST payable. A debit equal to the tax alone means the sales code is unmapped; that is the short-journal look-alike above.

Who looks for these, and when

The person who pressed FINAL gets no message about a failed posting, and none of the screens on this page sends one later, so the check is a person’s job, done on a schedule:

• Whoever owns the chart of accounts runs Missing Journal before each month is closed, for every document type the company uses, and again in the first week after a new company goes live. An empty list means no FINAL document of that type and range, with an amount, is still waiting for its first journal. It does not cover a type the listing does not offer (a Sales Refund Note and a Sales GIN Stock Out are not among its 16), nor a document still marked posted after its journal was removed; check those one at a time on the document itself.
• Whoever sets up a new company posts one test invoice and checks its journal before anyone sells from it (How you know it worked).
• Where sales arrive from another system, the morning check includes Missing Journal for the sales-invoice type (The morning check, Step 6).

Common mistakes

Related documentation