Cashbook

Every place your money is held — bank accounts, cash drawers, card-acquirer and e-wallet accounts — is a cashbook set up here, and every way money moves is a settlement method. Receipt vouchers, payment vouchers, POS and bank reconciliation can only pick from what is set up here.

Overview

The Cashbook applet defines every place money is held — bank accounts, cash drawers, card-acquirer and e-wallet accounts — as a cashbook tied to a company and a GL code, and every way money moves in or out as a settlement method (cash, cheque, bank transfer, card, e-wallet, voucher, points…). Receipt vouchers, payment vouchers, POS and the bank reconciliation all pick from what is set up here.

It also records money moving between cashbooks (Cash Transfer), corrections to a cashbook balance (Cash Adjustment), post-dated cheques waiting to be banked in, and provides the enquiry screens (Query Cashbook Transaction, Cash Level, Cashbook Discrepancy Checking) that finance uses at month-end. Each cashbook also carries the Weightage Configuration that the Bank Reconciliation auto-matcher uses. It is set up once by the finance administrator and then used daily by the cashier and the accounts clerk.

Where it fits

Modules: Core, Financial Accounting, POS.

Screens and menus

Gear (Settings) menu: Application Settings, Default Selection, Printable Format Settings, Branch Settings, plus the shared permission, webhook, feature-visibility, release-notes and applet-log screens. Personalisation: per-user Default Selection.

Cashbook

Create asks for Cashbook Code, Cashbook Name, Account Number, Company, Currency and GL Code. The edit screen has four tabs:

Settlement Method

Create asks for Code, Name, Sort Code (display order) and the Cashbook it settles into. The edit screen:

A Tax tab records tax codes against the method: country, then type, then code, with the rate taken from the code.

Settlement types: BANK_TRANSFER, CASH, CHEQUE, CREDIT_CARD, DEBIT_CARD, E_WALLET, FPX_EMANDATE, MEMBERSHIP_POINT_CURRENCY, OPEN_CREDIT, VOUCHER, OTHERS.

Cash Transfer

A cash document with a transfer number, transfer type (Bank In, TT, Cash), company, branch, reference number, transaction date, remarks and status, plus transfer lines of three kinds: Transfer From Cashbook (stored negative), Transfer To Cashbook (positive) and Transfer Charges (positive). Lines whose settlement type is POST_DATED_CHEQUE also carry a cheque date. Listing buttons: FINAL, VOID, SINGLE/MULTIPLE PRINT; edit buttons: FINAL, SAVE, CLONE.

Cash Adjustment

A cash document (document type, adjustment number, company, currency, transaction date, remarks) with lines of type Adjust In (positive) or Adjust Out (negative) against a cashbook. Listing and edit offer FINAL and SAVE only; there is no VOID button.

PD Cheque

Queue lists post-dated cheques not yet banked in (transfer no., document type and no., transaction date, cheque date, amount). Select rows, choose the receiving cashbook and its bank-in settlement method, and press BANK IN. History lists what has been banked in, with the origin, from and to cashbooks and the process status.

Enquiries

• Query Cashbook Transaction — one cashbook (or several), one period: an opening-balance row, then each line with document short code and number, branch, payee, reference, remarks, transaction date, cashbook, debit, credit, credit-card details and running balance. Rows drill down to the source document and its journal.
• Cash Level — one row per cashbook with its opening, in/out and closing for the dates you choose; filtered by company, cashbook and date. What the screen does not tell you is below.
• Cashbook Discrepancy Checking — transaction date, company, document short code and number, item code, document amount, cashbook amount and the difference.

Balances on Cash Level: where they come from

Nothing on Cash Level is stored. Each time you search, your browser downloads every cashbook transaction line dated inside the range and adds them up per cashbook — that sum is In/Out, money in less money out. Then, for each cashbook that made it onto the list, it asks for the Opening: every line in that cashbook dated before your From date, however old, added together. Closing is Opening plus In/Out, so it is the cashbook’s balance when your To date ends. When the applet setting HIDE_VOID_TRANSACTIONS is on, voided documents are left out of all three.

The date filter starts at today → today. Open Cash Level and search without touching the dates, and you see only the cashbooks that had a transaction today.

A cashbook that holds money but had no transaction in the date range is not listed at all, so any total you add up from the Closing column is less than the cash you actually hold, and nothing on the screen says a cashbook is missing. The rows are built from the transaction lines, and a quiet cashbook — a fixed deposit, a branch float nobody touched this week, a marketplace clearing account between payouts — has no line in the range to make a row from. Its balance is still there; Cash Level just does not show it. You will see it as fewer rows than the Cashbook listing has active cashbooks, or as a cash total well below what your bank statements and cash counts say.

Two ways to get a full cash position:

• Widen the range back. Set From to a date before your first transaction in BigLedger and To to the day you want the position for. Every cashbook that has ever moved now appears, and Closing is still each one’s balance at your To date — only Opening and In/Out now describe the longer period. On a busy group this downloads every line in that range into your browser, so expect it to be slow.
• Count and cross-check. Compare Cash Level’s rows with the active cashbooks on the Cashbook listing for the same companies, and read any missing cashbook in Query Cashbook Transaction, whose opening-balance row is shown whether or not the period has lines.

Cash Level has no PDF export: the button for it is switched off in the applet. A template uploaded on the Cash Level tab in Printable Format Settings is therefore not printed from this screen.

Configuration

Before you can use it

Applet settings

Application Settings and Default Selection save tenant-wide, so a change applies to every user of the applet; Branch Settings save per branch; Personalisation > Default Selection saves per user. Anyone who can open the gear menu can change them — the applet registers no permission for the settings screens.

Settings > Application Settings — six tabs. Every row below is rendered as a control, saved by the SAVE button and read by the applet.

Settings > Default Selection — Default Branch and Default Location pickers (DEFAULT_BRANCH, DEFAULT_LOCATION). Rendered but not consumed: no screen in this applet reads them.

Personalisation > Default Selection (per user) — the same two pickers plus DEFAULT_TOGGLE_COLUMN (SINGLE / DOUBLE) and DEFAULT_ORIENTATION (HORIZONTAL / VERTICAL); the last two are read by the cash transfer screens and the audit-trail listing to choose the one- or two-column layout.

Settings > Printable Format Settings — upload a printable format (code, name, file). The chosen default is what the transfer listing’s print button and the cash-document export use.

Settings > Branch Settings — per branch, six tabs saved to the branch settings record:

Document behaviour settings

Cash Transfer and Cash Adjustment are cash documents with a posting status, but the applet exposes no per-document behaviour switch beyond SAVE_CASH_TRANSFER_DETAILS, ENABLE_AUTO_POPUP and the printable settings above. No approval workflow, status-flow option or e-Invoice flag exists in this applet.

Feature visibility / permissions

The applet checks eleven client-side permission codes, one per hideable menu; a permission holder sees the menu even when the tenant has hidden it. Eight are registered; three are checked but not registered, so those menus can only be hidden for everyone:

Nothing in this applet reads the cashbook Members list; the bank-reconciliation, bank-statement and cashbook-transaction queries do, which is how Bank Reconciliation limits a user to the cashbooks they are a member of. Membership does not restrict any screen in the Cashbook applet itself.

Fields

Cashbook — create / Details

A cashbook also takes a Cashbook Name, the Account Number at the bank, the owning Company (which must exist), an account Currency, a free-text Description and an ACTIVE / INACTIVE Status. The four rows below are the ones that fail, or reach somewhere else.

Cashbook — Triggers & Limits

Low level trigger, high level trigger, facility amount and overdraft limit are four numbers stored on the cashbook. Nothing reads them — no alert fires when a balance crosses a trigger; they are informational.

Cashbook — Members

Cashbook — Weightage Configuration

A configuration tells the Bank Reconciliation auto-matcher how much each of four matching dimensions counts when it scores a bank-statement line against a cashbook line.

How the matcher uses it: the weights are taken from the cashbook’s active configuration; when there is no configuration each dimension weighs 0.25; a threshold outside 70–100 is only logged as a warning, not refused; One to One Matching skips the one-bank-line-to-many-cashbook-lines grouping.

Settlement Method — create / Details

The rest of the tab is descriptive: a Sort Code (display order in tender lists, max 255), a Settlement Type from the list under Screens and menus, an ACTIVE / INACTIVE Status, the gateway block (payment provider, PGW payment ID, PGW payment type code), an Installment period, the min / max threshold and settlement-limit fields, a Membership point currency and grouping Labels. All but the status and the point currency can be hidden by a setting. | Charges (mode, rate, absolute value, min / max limit, additional surcharge), Sending charges (same set), Surcharge to customer (mode, rate, absolute value, rounding precision, item code) | Charges tab | No | Applied on every receipt / cash-bill / payment settlement line that uses the method: the cashbook GL is debited net of the charge and the charge is posted to the company default SETTLEMENT_CHARGES; the cashbook transaction line is netted the same way. Charges also drive the amounts of the bank-in transfer created from the PD Cheque queue |

Cash Transfer

The header takes a Transfer Type (Bank In, TT or Cash), the owning Company and Branch, a Reference No and Remarks, the Transaction Date it posts on, and an ACTIVE / INACTIVE Status; each line takes its own Remarks. What is worth knowing is below.

Upload Cash Transfer — what the screen does not say. The file has thirteen columns — COMP_CODE, TRANSFER_TYPE, CCY_CODE, REF_NO, STMT_NO, TXN_DATE, HDR_REMARKS, STL_METHOD_CODE, LINE_TYPE, CASH_TRANSFER_AMT, LINE_REMARKS, POSTING_STATUS, BRANCH_CODE — and nine of them must be present as headers: company, branch, transfer type, currency, reference, date, settlement method, line type and amount. A header outside the thirteen is refused. The check runs in two stages, which is why a file can be accepted and still fail: the headers are checked at upload and the reply is immediate; the rows are checked by a queued job afterwards, which writes one error per field onto the row, and the upload screen itself shows no reason — open the uploaded file’s rows to read them. The values that pass are exactly Bank In, TT or Cash for the transfer type and Transfer From Cashbook, Transfer To Cashbook or Transfer Charges for the line type. The lines sharing a REF_NO are one transfer, and its from amount must equal its to amount plus its charges or every line of that reference is refused. A row with STMT_NO filled must name an existing transfer, which it updates; a blank one creates a new transfer — so re-uploading a corrected file with the numbers left blank creates duplicates rather than correcting anything.

Cash Adjustment

The header carries Company, Currency, Transaction Date and Remarks; each line names the Cashbook being corrected and an Amount, entered positive, with its own remarks.

Cash Transfer By Transaction

Listing columns: Transfer No, Doc Short Code, Transaction Date, Cashbook, Transfer Line Type, Settlement Method, Txn Amount, Description, Branch, Posting Status. The edit form shows the transfer no, posting status, transfer line type, current cashbook and amount read-only and lets you pick a new cashbook (required); SAVE is disabled until the cashbook differs from the current one. Use it to move a line that was posted to the wrong cashbook.

PD Cheque Queue / History

Queue columns: Cash Transfer No., Doc Type, Doc No., Date Txn, PD Cheque Date, Total Amount, Created / Updated Date. Bank-in inputs: receiving cashbook and its bank-in settlement method. History adds Process Status, Origin / From / To Cashbook.

Lifecycle and effects

Cashbooks, settlement methods, members and weightage configurations are master records (ACTIVE / INACTIVE); they do not post. The two cash documents behave differently:

Posting proof — Cash Transfer:

• Server document type: INTERNAL_CASH_TRANSFER; it is a cash document, not a generic document, so it carries no document-type signums.
• Amount signum: carried in the line amount — the applet stores Transfer From lines as −amount, Transfer To and Transfer Charges lines as +amount. Quantity signum: none (no stock).
• Dr/Cr equation: one journal line per transfer line; a negative amount becomes Cr of its absolute value, a positive amount becomes Dr. So Dr the To cashbook GL (and the charges GL) / Cr the From cashbook GL. The journal is AUTO, type TXN, dated on the transfer date.
• GL precedence: the sub-ledger for (company, line settlement item) → otherwise the cashbook that owns that settlement item, whose GL code gets a new sub-ledger on the company ledger. There is no header GL and no company default: a settlement item with no cashbook throws MISSING_CASHBOOK: STL_MTHD [code], a cashbook with no GL code throws MISSING_GL_CODE: STL_MTHD [code].
• Balance check: the journal is refused with TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES: Total Debits: …, Total Credits: … when debits and credits sum to zero, and with NO_JOURNAL_CREATED when both sides are zero; posting requires the document to be FINAL (CASH_DOC_POSTING_STATUS_NOT_FINAL) and reversal requires VOID (CASH_DOC_POSTING_STATUS_NOT_VOID).
• Stock processor: none.
• What VOID reverses: a reversal journal with debit and credit swapped on every line; the cashbook transaction lines soft-deleted, so the cashbook shows neither the original line nor a reversing one; PD cheque queue rows deleted.

Cashbook transaction lines: for FINAL transfers and adjustments every line except Transfer Charges becomes a cashbook transaction line, born fully unmatched (soft-deleted on VOID); a line whose settlement type is POST_DATED_CHEQUE is flagged post-dated with its cheque date and cheque number. Editing a FINAL document re-synchronises both the lines and the journal (matched by cash document line; orphans are soft-deleted) instead of creating a second set.

FINAL and VOID: the status first, then two postings — and pressing again finishes the job. In the backend running since October 2026, FINAL (or VOID) commits the status at once and then runs the cashbook-line posting and the journal posting straight after, as two separate steps. If one of them fails, the transfer still reads FINAL (or VOID) and that half is recorded on the document as failed, so a transfer can be FINAL with its journal and no cashbook lines, or the other way round. You see it as a FINAL transfer missing from Query Cashbook Transaction, or absent from the journal listing in Ledger And Journal. Fix the cause (usually a settlement method with no cashbook) and press FINAL (or VOID) again: when both halves are done it returns success and changes nothing; when one is missing or failed it runs that half again. Nothing is posted twice — the cashbook side keeps one live line per transfer line, and the journal side skips a transfer that already has a posted journal. Where the cashbook watchdog clock (CASHBOOK_TXN_WATCHDOG_PROCESSOR, every 15 minutes) is scheduled on your tenant in the Scheduler, it re-runs a half left undone for more than 20 minutes without anyone pressing anything; where it is not, the second press is yours to make.

FINAL edits are blocked once reconciled. Changing the company, transaction date, transfer lines or amount of a FINAL transfer whose cashbook lines have an active bank-reconciliation link is refused with “Please unreconcile this transaction from bank recon first …”. Remarks- and reference-only edits pass.

Post-dated cheques. On FINAL, every cashbook line flagged as a post-dated cheque creates a PD Cheque queue row (source document, cashbook, settlement method, amount, cheque date, payee, transaction number). Queue rows also arrive from generic documents (receipt vouchers) that carry a post-dated cheque. Bank In on the queue builds a new INTERNAL_CASH_TRANSFER with three lines — from the cheque’s cashbook (negative), to the chosen cashbook (the cheque amount less the sending settlement method’s charges, applying its absolute / ratio, min and max rules) and a Transfer Charges line for the difference — saves it through the normal transfer create path, writes its cashbook lines and a History row, then deletes the queue row. Voiding the source transfer deletes its queue rows.

Journals in the Chart of Account’s fiscal periods. Cash documents are not generic documents, so the LOCK_TXN / LOCK_ALL check on documents does not apply to them; their journals are AUTO and therefore also bypass the LOCK_GL check on manual journals (see Chart of Account).

Where a cashbook transaction line comes from, column by column

Most cashbook transaction lines are not written by this applet at all. They are written when a generic document — a receipt voucher, a payment voucher, a cash bill, a sales invoice settled at issue — reaches FINAL and its primary processor queues the cashbook subscriber. That subscriber reads only the document lines whose transaction type is STL_MTHD (the payment lines), and ignores every goods line on the document. If the payment lines sum to zero it writes nothing at all and still marks the document’s cashbook posting as done.

This is the answer to “where did this figure come from?” on the Reconcile tab, and almost none of it is visible on the document:

Every save of a finalised, cashbook-posted document re-synchronises these lines rather than creating a second set: lines are matched by document line, existing ones are updated in place and any new payment line gets a new cashbook line. The amount is the one field that is not rewritten blindly — see the guard below.

Amount changes are refused while the line is reconciled. If the document amount actually changes and the cashbook line still has an active bank-reconciliation link, the save is rejected with a message naming the cashbook, the reconciliation and its month. If the amount has not changed, the amount and open-amount columns are deliberately left untouched — that is what lets you correct a reference, a remark or a payee on a reconciled document without disturbing the match. The refusal is not universal: the Settlement Adjustment screen reaches the same lines without it (see Bank Reconciliation).

When the line was never written at all. The document’s cashbook posting status is the record: blank means the subscriber never ran, POSTED means the lines exist, VOID means they have been removed. A FINAL receipt voucher, payment voucher, cash bill or cash transfer with a blank cashbook status and no cashbook line is exactly what Financial Report › Error Checking › Trace Document reports as Missing Cashbook, and its Resolve button posts the lines without voiding or re-keying the document. Posting is idempotent: if lines already exist, the request marks the document POSTED and writes nothing.

After FINAL: who writes a cashbook line

Save writes nothing to a cashbook. A cashbook line appears only after a document is finalised, and it is written by a background job that FINAL queues, a moment later — not by the screen you pressed FINAL on. The writers are:

• A generic document’s payment lines — receipt voucher, payment voucher, cash bill or POS bill, an invoice settled at issue. One cashbook line per payment line, in the cashbook named on that line’s settlement method.
• A cash transfer or cash adjustment — one line per transfer or adjustment line, except Transfer Charges lines.
• Bank In on the PD Cheque queue — through the cash transfer it creates.
• Settlement Adjustment in POS General — it rewrites the payment lines of a finalised bill, and its cashbook lines with them.

A journal never writes one. A manual journal against your bank’s GL code moves the ledger and leaves the cashbook as it was, so the bank’s own entry for it has no cashbook line to be matched with. That is why a transfer between your own accounts is a cash transfer and not a journal: the transfer writes the ledger and both cashbook lines.

The job reads the set-up as it stands when it runs: the cashbook named on the settlement method, that cashbook’s GL code, and the method’s charges. The line takes the document header’s transaction date and the payment net of the method’s charges. Change the cashbook named on a method and the lines already written stay where they were — until somebody saves one of those finalised documents again. Every save re-synchronises the document’s cashbook lines (see above) and re-reads the cashbook from the method, so that document’s line moves to the new cashbook and takes the header’s current date. The reconciliation guard checks only the amount, so the move goes through even when the line is already matched to an entry of the old cashbook’s bank. When a bank account is replaced, a safer pattern is a new settlement method for the new cashbook, with the old method’s branches unticked: old documents keep the old method, so they stay on the old cashbook whenever they are saved.

Nothing at FINAL checks that a settlement method has a cashbook. The till takes the customer’s money, the bill goes FINAL, and the job then fails with MISSING_CASHBOOK: STL_MTHD [code] — no cashbook line and no journal for that document. Nobody is told at the counter. You find it as a FINAL bill that Query Cashbook Transaction does not show, or on Financial Report › Error Checking › Trace Document as Missing Cashbook. Since October 2026 the backend also carries a cashbook watchdog clock: where it is scheduled on your tenant, it retries every FINAL document whose payment lines have no cashbook line, from 20 minutes after the document was last saved — at most four failed tries in a rolling 24 hours, then it waits for the window to roll on. It retries; it does not attach the cashbook for you. Once you name the cashbook on the method, the next pass posts the line; where the clock is not scheduled, Resolve on Trace Document posts it.

The job here belongs to whoever creates settlement methods, normally the finance administrator, and the moment to do it is before anybody can tender the method: name its cashbook and tick its branches first. For example, a new e-wallet method opened at GS-PEN-01 on the 1st with no cashbook named takes payments all day at the counter, and none of them reaches a cashbook or the ledger until somebody notices. To know you got it right, open Query Cashbook Transaction for that cashbook on the day of the first sale through the method. The sale should be there, dated on the bill, at the amount less the method’s charges. If it is not there half an hour later, run Trace Document on the bill.

Which balance is which

A cashbook figure appears in four places, and they are not the same kind of number:

• Query Cashbook Transaction and Cash Level are live figures: they add up the cashbook lines at the moment you search. The opening is every line dated before your From date. Nothing is stored, so a document finalised a minute ago is in it as soon as its job has run, and a voided one drops out the same way.
• A bank reconciliation session is a snapshot: it stores its cashbook opening and closing when you create it. Since October 2026 a background job refreshes the stored figures every 30 minutes, where that job is scheduled on your tenant; where it is not, they stay as they were at Create. Any cashbook line written, voided or re-dated on a cashbook with an active session queues that refresh. See Bank Reconciliation.
• The cashbook’s GL code in the ledger (Ledger And Journal, the trial balance) is the sum of journal lines — a different book, written by a different job. It agrees with the cashbook only when every movement wrote both halves.
• Triggers & Limits are numbers you typed. No balance is compared with them.

Why the cashbook and its GL code disagree, and how to tie them out

Five movements write one half and not the other:

1. A manual journal against the bank or cash GL code — ledger moves, cashbook does not.
2. A cash adjustment — cashbook moves, ledger does not (no journal by design).
3. A Transfer Charges line on a cash transfer — journal only. If you picked the bank’s own settlement method on that line, the ledger puts the fee back on the bank account while the cashbook shows it gone, as the bank does.
4. A document whose payment method had no cashbook, or whose cashbook had no GL code — MISSING_CASHBOOK stops both halves; MISSING_GL_CODE stops only the journal, and the cashbook line is still written.
5. A cash transfer with one half failed — see FINAL and VOID above.

So tying each bank and cash GL code to its cashbook is a person’s job, not the software’s. The accounts clerk does it at every month-end, before matching the month. If several cashbooks share one GL code — several branch cash floats on one cash account, for example — compare the GL with the sum of all of them.

How you know the tie-out is done

The difference between the cashbook’s closing and the GL code’s balance at the same date is fully explained by a short list of named documents, each one of the five movements above. A difference you cannot name is not done, however small.

Worked example — GadgetSphere Sdn Bhd, end of March. In Query Cashbook Transaction, CASH-PRI-KV01 closes at RM 182,450.00 on 31 March. The trial balance shows the same GL code at RM 182,115.00 — RM 335.00 apart. In the cashbook’s lines you find a RM 300.00 Adjust In from a cash adjustment, a counting correction nobody journalled. In the GL code’s journal lines you find a RM 35.00 bank-charges journal with no cashbook line. RM 182,450.00 − RM 300.00 = RM 182,150.00, and RM 182,115.00 + RM 35.00 = RM 182,150.00: both differences are named, and the tie-out is done. Then decide which side is right. The primary bank did take the RM 35.00, so the cashbook needs it: remove the journal with VOID in Ledger And Journal and post the charge as a payment voucher, which writes both halves and leaves one cashbook line for the bank’s entry to match. If the RM 300.00 really was found cash, journal it; if it was a miscount, the adjustment was the mistake.

Related applets

• Chart of Account — the GL code behind every cashbook and the company ledger that receives the cash transfer sub-ledgers.
• Organisation — companies and branches.
• Bank Reconciliation — matches a cashbook’s lines to the bank statement using the Members and Weightage Configuration set here; a reconciled transfer can no longer be re-dated or re-amounted.
• Receipt Voucher and Payment Voucher — money in and out through settlement methods; post-dated cheques received there queue here.
• POS General — tenders are settlement methods; the per-branch defaults per tender type come from Branch Settings here.
• Ledger And Journal — where cash transfer journals are visible (cash adjustments post none).
• Doc Item Maintenance — settlement methods are items of type STL_MTHD; the customer surcharge is billed as an item.

Troubleshooting

Related documentation

• Bank reconciliation guide — the month-end procedure that starts from a cashbook.
• Financial Accounting module and Opening balances.
• Core module.