Receipt Voucher (Internal)

Record money a customer pays you and apply it to what they owe. Finalising posts the cashbook line you later match against the bank statement, plus the debtor journal. A receipt finalised without a contra stays as an unapplied customer credit until you contra it, and a wrong settlement is corrected on Settlement Adjustment rather than by voiding.

Overview

The Receipt Voucher (Internal) applet records money coming in from a customer — cash, cheque, bank transfer, card or any other settlement method — and applies it to the customer’s open documents by contra. An accounts-receivable clerk creates the voucher, adds one or more settlement lines, contra-links the sales invoices being paid, and finalises it. FINAL posts the cashbook transaction (which then appears in Bank Reconciliation) and the debtor journal. The applet also carries optional Revenue and Expense lines for receipts that are not against an invoice, and post-finalisation adjustment screens so a wrong settlement can be corrected without voiding.

Video walkthrough

Where it fits

Modules: Financial Accounting and Sales.

Which routes write a receipt voucher, and which do not

Four routes write a Receipt Voucher (Internal). (Internal) marks the back-office voucher your finance staff key, as opposed to one a shopper or a portal reaches.

• Keyed in this applet — the normal case, finalised with the FINAL button.
• Imported from a file — rows marked FINAL in the file skip the FINAL button’s checks (Import Receipt Voucher).
• A bill paid online through BigLedger’s billing applet, on the ERP payment route. When the gateway confirms the payment, a background job writes the receipt voucher, finalises it and contras it against the bill that was paid. It writes one voucher per gateway reference, so a repeated confirmation does not write a second.
• The other side of an intercompany payment. A payment voucher one group company raises to another can create the receipt voucher in the receiving company (Intercompany).

Two routes take money from customers and do not write a receipt voucher:

• A storefront checkout. The gateway’s confirmation turns the cart into a FINAL sales order and writes the payment onto that order as a settlement line; the cashbook job posts it to the settlement method’s cashbook. How that payment is then meant to meet the invoice raised from the order is an open question with BigLedger, so do not look for a receipt voucher to apply, and do not key one for the same money.
• A cash bill at the till. The bill settles itself: its goods must equal its settlement lines plus any contra before it can be finalised, and its own settlement lines write the cashbook lines. A receipt voucher keyed for a cash bill would bank the same money twice.

A marketplace payout is a third case: the accounts clerk books it here by hand (see Related applets).

Screens and menus

Creating a voucher

There is no separate create form. + on the listing saves an empty temporary voucher at once and opens the edit form on it, with every tab below — Contra included — available before anything is filled in. The voucher stops being temporary by itself once its required header fields are filled (see Lifecycle); until then SAVE does nothing useful.

There is no Posting tab on this applet and no Delivery Details tab. TraceDocument, below, is what does that job here — and it does it better, because it shows the rows that were written rather than a status word about them.

Edit form tabs

Default order (changeable under Settings > Default Selection > Details Tab Ordering):

Top action buttons

The edit form’s action bar is FINAL, CLONE, VOID and SAVE. DISCARD is on the listing, for the ticked vouchers (HIDE_GENDOC_DISCARD_BUTTON off or SHOW_GENDOC_DISCARD_BUTTON). On a foreign-currency voucher’s base-currency copy — the second record FINAL creates, see What FINAL does — the whole action bar is hidden.

The rule that FINAL needs a settlement line is enforced by this screen, at the point of choice: the edit form hides FINAL without one, and the listing’s FINAL refuses the ticked vouchers that have none (Unable to post the document to FINAL … Invalid payment.). The server does not repeat it, so a receipt finalised through the API with no settlement line is accepted — no cashbook line follows, and TraceDocument’s Cashbook Txn grid stays empty. An integration that writes receipts should refuse that case itself.

Import Receipt Voucher

Upload a CSV/Excel file, review the Checking tab for row-level errors, fix or re-upload, then process. The menu is removed by HIDE_IMPORT_RECEIPT_VOUCHER_MENU.

The file’s Posting Status column decides what each voucher becomes, and it is all-or-nothing per file: if any row fails, every voucher the file created is deleted and the file is marked FAILED — but a contra the file had already written for those vouchers is not removed with them, so check the invoices the file was paying before you re-upload.

Configuration

Before you can use it

Applet settings

Settings (gear icon) → System Configuration: Application Settings (the shared Field Configuration screen), Default Selection, Branch Settings, Printable Format Settings, Email Template, Custom Resource Bundle Configuration, Custom Field Placement, Webhook, Feature Visibility, the permission screens, Release Notes and Applet Log. Personalization holds your own Default Selection and sidebar. 184 keys reach this applet and 91 of them begin HIDE_ — one switch per field, column, tab or button, visible the moment you save. The five below change what the applet will let you do; three of them decide a figure the customer’s ledger then lives with, and one — the settlement date — changes far less than its name says. How settings are stored and who they apply to.

Two things to know before you change anything on this screen. First, the name in italics under each setting is the applet’s internal key. It is there so you can match what you are looking at to what support asks you about; it is not a stable name and it can be renamed, replaced or dropped when the applet is updated, so do not build a script or an integration around one. Second, a setting can be switched back but it cannot be returned to never saved: the first time anybody saves this screen, every toggle on it is written into your tenant’s settings at whatever it was showing, and the applet stops falling back to its own built-in default. The Default when never saved column above is what you give up at that moment — worth reading before the first save rather than after. Checked against the product on 17 September 2026.

On the screen and doing nothing

These keys are saved with the settings but nothing reads them — most never appear on a screen at all:

• The four Department enable keys (dimension, profit centre, project, segment) — declared in the model with a form control on the shared screen but no toggle rendered anywhere, and read by nothing here or in the backend. The panel’s MANDATORY_* partners are the controls you can see, and they do work, which is the confusing part: you can make a dimension compulsory on a line and you cannot turn it on.
• Filter by today’s transactions — declared in the model with no control on any screen, read by nothing. (In the Deposit applet it is read and still has no effect.)
• Validity date required — declared in the model with no control on any screen and no reader; the Validity Date field is never made required by it. Earlier versions of this page listed it as a working requirement, then as rendered; it is neither.
• Default company — saved by Default Selection when you pick a Default Branch and never read by a screen; the company comes from the branch you pick, not from this key.
• Allow contra above the document’s open amount — has a switch on the settings screen, but only an unreachable contra form reads it. The contra dialog you actually use follows Let a receipt be allocated to more than it is worth, above.
• Hide the FINAL button (the short form, not the HIDE_GENDOC_FINAL_BUTTON setting the button table names) — has a switch and no reader.
• Show the document delete button — read by the edit form and then drives nothing: there is no Delete button on a receipt voucher. Use DISCARD on the listing.

Branch Settings is a different screen and it does matter. Per branch it holds Rounding Five Cent, Item Category Filter, Menu List, Pricing Scheme, Printable Format, and Default Settlement Method — which decides the settlement methods offered on the Settlement tab at that branch and which of them is pre-selected. In the current build these rows are shared with the POS General applet’s branch settings, so changing them here changes the till as well.

Document behaviour settings

Approval workflow: not configurable in this applet beyond the Checked By / Approved By fields, which are informational.

Who can change what

Server-side. TNT_API_DOC_INTERNAL_RECEIPT_VOUCHER_{CREATE,READ,UPDATE,DELETE}_TGT_GUID. These are the only permissions that can return a 403.

Client-side permissions for this applet: 19. Sixteen are the SHOW_* partner of a HIDE_* setting — the action buttons, the Revenue and Expenses tabs, the Trace Document tab, the document-number and client- reference fields. The three that do something else:

• SHOW_EDIT_SETTLEMENT_FINAL — opens Payment Adjustment on a finalised voucher, which is how a settlement line is corrected after the cashbook has already been posted — but only where the post-FINAL settlement editing setting is also on. The most consequential code on the applet.
• SHOW_DELETE_CONTRA — removes an allocation that has already been applied to an invoice, restoring that invoice’s outstanding balance.
• SHOW_TRACE_DOCUMENT_TAB — the trail from the receipt back to what it settled.

Listed as a permission and doing nothing. ENABLE_EDIT_SETTLEMENT_DATE also appears in the permission list for this applet and it is a setting, not a permission — the applet reads it only from the applet settings, never from what a role has been granted. Granting it to a role changes nothing; the behaviour is in the table above, and it is tenant-wide. Earlier versions of this page listed it here as a per-user grant.

Fields

Main Details

Settlement line

Settlement Method (from the branch’s assigned methods), Settlement Type, Amount, Date, Reference, Remarks, Cheque No, Cheque Date, Card Type, Voucher No, Points and Cash-back fields for loyalty settlements, and Month / Year / Settlement Group filters in the picker.

Revenue and Expense lines

Item code and name, quantity, UOM, unit price (inclusive of tax), tax, transaction amount, and department codes (segment, dimension, profit centre, project). Revenue lines post like sales lines. An Expense line is a deduction the customer took — it reduces what was banked against what the customer is credited with, and it posts as a debit on the sales side, not to an expense or purchase account, unless the item is a GL-code item that carries its own GL code. See the journal table under What FINAL does.

Contra

A search dialog over the customer’s open documents (filterable by document type) with the amount to apply. The total contra cannot exceed the receipt’s open amount unless ALLOW_EXCEED_CONTRA is on.

Lifecycle and effects

What FINAL does:

1. Changes the posting status to FINAL and queues the postings that follow. Only the FINAL-time validations can stop this step — a locked fiscal period, a second FINAL, and a foreign-currency voucher with no exchange rate (Generic Document exchange rate is required before posting to FINAL); nothing about cashbooks or GL codes is checked here. A foreign-currency voucher is also given a finalised base-currency copy, which is what posts; its edit form has no action buttons. An imported voucher marked FINAL in the file skips this step — see Import Receipt Voucher.
2. The cashbook posting (FINAL documents only) creates one cashbook transaction line per settlement line in the cashbook behind that settlement method. These are the lines Bank Reconciliation matches. A settlement line whose method has no cashbook fails this job with MISSING_CASHBOOK: STL_MTHD [code]; the voucher stays FINAL with no cashbook line. Once a cashbook is named on the method, the line is posted by the watchdog clock where your tenant schedules it (since October 2026), otherwise by Resolve on Trace Document. Settlement lines that add up to zero write no cashbook line at all, and the voucher is still marked as posted to the cashbook.
3. The journal posting posts the journal; a cashbook without a GL code fails it with MISSING_GL_CODE: STL_MTHD [code] Two places show you that it failed, and neither is a Posting tab — this applet has none. The voucher’s own TraceDocument tab shows an empty Journal Txn grid, which is the symptom; Financial Report › Error Checking › Trace Document gives the reason and a Resolve button:

The customer line is whatever balances the rest, so an Expense line credits the customer with the receipt plus the deduction — which is the point of it — but it does so by debiting sales and output tax, not an expense account. A RM 1,000 receipt with a RM 20 bank-charge Expense line credits the customer RM 1,020 and debits RM 20 to SALES (or to the GL code of a GL-code item, if that is what the line uses). How to spot it: after the first voucher with an Expense line, read its Journal Txn grid on TraceDocument and check which account the deduction landed on. Whether this should post to a purchase-side or expense default is an open question with BigLedger; the page states today’s behaviour.

Foreign-exchange gain or loss is not part of this journal. It is a separate journal, written per contra when the contra is created, on FOREX_GAIN / FOREX_LOSS; a foreign-currency receipt finalised without a contra has none until it is contra’d.

4. The contra is not one of those jobs. Once the finalise call (or any edit-save) returns, the applet sends a second request carrying the new Contra-tab rows; the backend writes each mirrored pair and re-sums both documents’ contra and outstanding balances inside that request. If the second request fails — missing API_TNT_DM_ERP_FI_GENERIC_DOC_ARAP_CONTRA_UPDATE, expired session, tab closed — the toast reads Documents contra unsuccessfully, nothing retries, and the receipt is FINAL with its cashbook line and journal and no contra. Because the effect also fires on an ordinary save, a contra keyed on a draft voucher is live as soon as the draft is saved. The listing’s FINAL fires it too, and it sends whatever contra rows the screen still holds unsent — including rows keyed on the last voucher you opened and left without saving, until you press + or open another voucher, which replaces them with that voucher’s saved contras. How to spot it: after a bulk FINAL from the listing, open the voucher you last had open and check its Contra tab for allocations you did not mean to keep. Before a bulk FINAL, open any voucher from the listing first.

Saving a change to the amount of a finalised settlement line whose cashbook line is already reconciled is refused: Please unreconcile this transaction from bank recon first before changing the amount: Cashbook [name] - Bank Recon [name] (month).

SAVE on a draft writes nothing to a cashbook or the ledger. On a FINAL voucher every save re-synchronises its cashbook lines with its settlement lines, and it re-reads the cashbook named on each settlement method as it is now. So if somebody has pointed the method at a different cashbook since FINAL, the next save of an old receipt moves its line there — reconciled or not, because the refusal above protects only the amount of a reconciled line. When a bank account is replaced, give the new cashbook a new settlement method rather than re-pointing the old one (why).

A Payment Adjustment is not refused, and it unreconciles. The tab sends a settlement adjustment, which the Settlement Adjustment menu then lists: the new settlement lines must add up to the old total (The total settlement amount must be the same as the previous settlement amount.), and an identical set is refused as no change. It rewrites the settlement lines, replaces the voucher’s journal with one rebuilt from the corrected voucher — when the voucher’s journal flag reads posted; with any other flag it posts a new journal beside whatever is already there — and removes and re-creates every cashbook line of the voucher. Removing a matched cashbook line hands its amount back to the bank statement line and deletes the match, so a month you had reconciled shows the receipt’s bank lines unmatched again and nothing on the screen says why. Check whether the voucher’s cashbook lines are reconciled before adjusting it, and re-match them after.

VOID reverses the journal (the reversal carries the original transaction date), soft-deletes the cashbook lines — handing any matched amount back to the bank statement line — and deletes every contra the voucher takes part in, re-summing each invoice’s balance, so the invoices go back to outstanding. It is offered on any FINAL voucher; there is no e-Invoice lock on receipts. See What a void undoes.

Where each figure comes from

Five figures follow from one FINAL receipt, and only one of them is worked out when you look at it.

• The cashbook line — on the voucher’s TraceDocument › Cashbook Txn grid, in Query Cashbook Transaction, and the line Bank Reconciliation matches. Written once by the cashbook job after FINAL, from the voucher as it is then: one line per settlement line, in the cashbook named on that line’s settlement method, at the amount less the method’s charges, as money in, dated the voucher’s date, described by the settlement line’s Remarks, and naming the payer from the Account tab’s billing name before the entity’s own name. A cash-back line on a receipt is written as money out. A later save re-synchronises it (above).
• The journal — written by its own job, which reads the company default GL codes and the payer’s AR/AP type as they stand when it runs. The type comes from the payer’s link to the voucher’s company first and from the entity’s own type otherwise, so one company can be a trade customer of GSD and a non-trade debtor of GS; changing the type changes the next voucher that posts, and a re-post. The payer line is whatever balances the rest, so it is only built when a balance is left.
• The outstanding balance of the receipt and of each invoice it paid — stored on each document and rewritten inside the contra request itself: the document’s opening figure plus every contra against it. This is the balance the Debtor Report and the statement read, and it moves the moment the Contra tab saves. The voucher also carries a second, older figure — its own amount less its own settlement lines — which a contra never changes (Troubleshooting).
• A past month on the historical aging — not worked out from the documents but read from month-end rows a scheduled job stores at 01:00 on the 1st, one for every FINAL document still carrying a balance. A contra keyed or deleted on this voucher’s Contra tab works both documents’ stored months out again, counting the contra only in months ending on or after its contra date. Changing a contra’s date in place does not. So: a corporate client of GadgetSphere Distribution pays a RM 12,400 March invoice by transfer on 31 March; you key the receipt on 2 April, dated 31 March, with the settings as they come, and the contra is dated 2 April — March’s stored month still shows the invoice open, with the receipt beside it as an unapplied credit. The client’s total for March is right; only the listing surprises you. The contra-date setting in Document behaviour settings dates new contras on the voucher’s date instead. The full mechanism.
• A bank reconciliation session’s cashbook opening and closing — stored when the session is created. Since October 2026 a background job refreshes them every 30 minutes where that job is scheduled on your tenant, and every cashbook line this voucher writes, re-synchronises, re-creates (Payment Adjustment) or removes (VOID) on a cashbook with an active session queues that refresh. Where the job is not scheduled, the figures stay as they were at Create.

The receipt desk: matching, applying, chasing

The applet records money that has arrived. It does not see the bank, and it does not decide which invoice a payment was for. Three jobs stay with people.

• Matching the money. A receipt is keyed from the bank statement, a remittance advice or the cheque in hand. Date it on the day the money reached the bank, because every figure above takes the voucher’s date; the person who matches the bank then pairs each receipt’s cashbook line with the bank’s own line.
• Applying it. Which invoice a payment settles is the customer’s instruction, usually on the remittance advice. Where none came, ask before you contra: a receipt applied to the wrong invoice leaves the other one ageing, and the customer’s statement disagrees with their own records. A receipt left unapplied is a credit on the customer’s account until somebody applies it.
• Chasing the difference. A customer who pays RM 4,950 against a RM 5,000 invoice — their bank kept a fee, or they disputed a line — leaves RM 50 that somebody has to own. Two ways to handle it, and the choice is your group’s policy, not the software’s: apply what was paid and leave RM 50 open on the invoice until a credit note, a further receipt or a write-off clears it; or add the RM 50 as an Expenses line so the customer is credited in full — remembering that an Expenses line posts on the sales side today unless its item carries its own GL code (see the journal table above). Allocating more than the receipt is worth is not a third way: it clears the invoice and leaves the difference sitting on the receipt.

How you know a receipt run is done

Run these for each day’s receipts, before the day’s bank lines are matched:

1. Every receipt of the run is FINAL, and its TraceDocument shows a Cashbook Txn line for each settlement line — the amount less any method charges, on the voucher’s date — and a Journal Txn grid that credits the payer with the amount you expected.
2. In Query Cashbook Transaction for the receiving cashbook, the day’s lines add up to what reached the bank that day.
3. Each invoice you applied a receipt to shows its outstanding reduced by exactly the contra on the Debtor Report; every receipt with nothing applied is one you meant to leave unapplied, and you can say why.

Until every unapplied receipt and every short payment is named to a customer, the run is not done.

Related applets

• Sales Invoice (Internal), Sales Debit Note (Internal), Sales Credit Note (Internal) — the documents a receipt is applied to.
• Tiktok Sales Order Applet — marketplace orders. TikTok’s settlement job is not registered, so no TikTok payout becomes a receipt voucher on its own; the accounts clerk books it (Reconciling Marketplace Payouts).
• Payment Voucher (Internal) — the outbound twin; both share the settlement, contra and adjustment mechanics.
• Cashbook Applet — where settlement methods get their cashbook and GL code.
• Bank Reconciliation — matches the cashbook lines this voucher writes. A match guards only the line’s amount: a later save, a Payment Adjustment or a VOID can still move or remove a matched line (see Lifecycle and effects).
• POS General — a cash bill at the till settles on the bill itself and needs no receipt voucher (which routes write one).
• Customer Maintenance — the customer’s AR type decides the debtor account.
• Chart of Account Applet, Organisation Applet — default GL codes, branches, numbering.
• Ledger And Journal, Debtor Report, Statement of Account — where the posting is reviewed.

Troubleshooting

Related documentation

• Bank reconciliation guide
• Financial Accounting module