Payment Voucher (Internal)

Record money you pay out: a supplier’s invoices, an expense paid directly, or a refund to a customer. Each payment line becomes its own cashbook transaction, which is what you later match against the bank statement, and a voucher that has already posted is corrected on the adjustment screens instead of being voided.

Overview

The Payment Voucher (Internal) applet records money going out: paying a supplier’s invoices, paying an expense directly (rent, road tax, a utility bill), or refunding a customer. An accounts-payable clerk creates the voucher for the payee, adds the expense lines being paid (if any), adds one or more payment lines (cheque, bank transfer, cash, card), contra-links the purchase invoices being settled, and finalises. FINAL posts one cashbook transaction per payment line — the lines Bank Reconciliation later matches — and the creditor journal. Settlement Adjustment and Expenses Adjustment screens let authorised users correct a finalised voucher without voiding it.

It is also the voucher finance uses to pay staff: a claim the claim cycle hands to finance, an advance, a commission payout. The claims applets post nothing themselves; the cycle’s PV Details Report lists each claim line with its GL code and tax, and you key this voucher from it (paying a staff claim). (Internal) in the name marks the back-office applet your finance staff use, as opposed to one a customer or a portal reaches.

Where it fits

Modules: Financial Accounting and Purchasing.

Screens and menus

The applet also looks for a per-user exception to each of the first three switches, but no such permission is registered for this applet, so none can be granted from the permission screens: once File Import, Intercompany or File Export is hidden, it is hidden for every user (checked 7 October 2026).

Edit form tabs

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

Top action buttons

Intercompany

A voucher whose Account tab carries intercompany data is picked up after FINAL by a background job that reads the branch’s intercompany setting. In automatic mode the job creates the mirror receipt voucher in the other company straight away. In manual mode the voucher lands in the Intercompany queue as Unprocessed, and Process creates the mirror (the backend maps the payment line’s settlement method across); processed entries move to the Processed tab. Either way the mirror is a draft, unless the setting has Auto Final Target Doc switched on.

File Import and File Export

File Import: upload the CSV/Excel, review the Checking tab, fix rows or re-upload. File Export: choose a transaction date range, click Generate CSV, download from the generated row.

Configuration

Before you can use it

Applet settings

Settings (gear icon) → 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. 178 keys reach this applet and 111 of them begin HIDE_ — one switch per field, column, tab or button, and you see what one did the moment you save. The seven below change what the applet will let you do, or who is allowed to see what, or what date the cashbook ends up with. 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 appear on the settings screen but nothing in this applet, the shared settings screen or the backend reads them:

• Three keys mean edit expenses after final and only one of them is real. The setting is ALLOW_EXPENSES_EDITING_AFTER_FINAL and the permission is ALLOW_EDIT_EXPENSES_AFTER_FINAL; ENABLE_EDIT_EXPENSES_FINAL is read by nothing. If a configuration note or an API payload names it, it does nothing.
• Enable edit settlement date — not shown for this applet (the shared screen’s gate hides it for this applet code) and read by nothing in this applet or in the backend; the applet uses ENABLE_EDIT_PAYMENT_DATE instead, which is the one that moves a payment date here.
• 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 work, so a dimension can be made compulsory on a line and shows unless hidden; its enable key cannot be turned on.
• Filter by today’s transactions — declared in the model with no control on any screen, read by nothing. Default pricing scheme — offered on Default Settings, saved, read by nothing.

Document behaviour settings

Approval workflow: not configurable in this applet.

Who can change what

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

Client-side permissions registered for this applet: 40. Most are the SHOW_* partner of a HIDE_* setting — the action buttons, the menus, and twenty-odd expense-line columns. The four that matter, and all four are half of a pair:

Fields

Main Details

This screen has no Tracking ID, Permit No or Validity Date field, whatever the settings say; a voucher keeps any such value it was given another way, and saving an existing voucher here does not clear it.

Account

Entity Details (payee code, name, type, identity, currency, status), Payee (bank details / cheque name; may differ from the entity with ALLOW_DIFFERENT_PAYEE_THAN_SELECTED_ENTITY), Intercompany (target company).

Expense line

Item or GL code (via Search Item / Search GL Code), description, quantity, UOM, unit price, discount, tax code, WHT code, amounts, department codes, costing details, issue link, attachments.

Payment line

Settlement Type and Method (from the branch’s assigned methods), Amount, Date, Remarks, Reference; per method: Cheque No and Cheque Date, Transaction No (bank transfer), Card Type, Voucher No, Points, Cash-back.

Contra

Search the payee’s open documents, tick one or more, enter the contra amount per document. Zero-value documents (for example free-of-charge items) cannot be contra’d — the contra engine silently drops any contra whose amount is zero.

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, or a foreign-currency voucher with no exchange rate; nothing about cashbooks or GL codes is checked here. A foreign-currency voucher is first copied into a base-currency copy, and it is that copy which is finalised and posted; on a tenant set up to skip those copies, the voucher is finalised with no ledger posting at all.
2. The cashbook posting (FINAL documents only) creates one cashbook transaction line per payment line in that method’s cashbook — these are what Bank Reconciliation matches. A settlement method without a 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. Payment lines that add up to zero write no cashbook line at all, and the voucher is still marked as posted to the cashbook. A voucher that is not FINAL, or whose method points at a different cashbook, will not appear there.
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, on either the create form or the edit form. The voucher’s own Trace Document tab shows an empty Journal Txn grid, which is the symptom; Financial Report › Error Checking › Trace Document gives the reason and a Resolve button. What the journal contains is set out below.

What the FINAL journal posts

The journal is built on the company’s primary ledger from the company default GL codes, line by line:

How the sides come out in practice. A voucher that only pays supplier invoices posts Dr supplier, Cr bank. A voucher whose expense lines add up to its payment has no payee line at all: Dr expense, Dr input tax, Cr bank. A charge on the payment method is posted as a credit on this voucher, on the same side as the payment line: the bank is credited with the payment less the charge, the settlement-charges account with the charge, and the payee’s account is debited with the full payment. If your payment methods carry charges, read the journal of the first voucher that uses one before you rely on it.

A line that finds no account is left out, and the payee’s account absorbs it. An expense line with no GL code anywhere in the chain above, a tax amount when there is no INPUT_TAX default, or a charge when there is no SETTLEMENT_CHARGES default is dropped from the journal without an error. The payee line is worked out last, as whatever balances the rest, so it grows or shrinks by exactly the dropped amount. Pay RM 1,060 for a RM 1,000 repair plus RM 60 tax with no INPUT_TAX default, and the journal posts Dr repairs RM 1,000, Dr supplier RM 60, Cr bank RM 1,060 — a RM 60 debit on the supplier that nobody keyed. How to spot it: open the voucher’s Trace Document › Journal Txn grid (or the journal in Ledger And Journal). Every expense line, every tax amount and every charge should have a line of its own; a payee line on a voucher whose expenses equal its payments, or a payee amount that differs from the invoices you settled, is a dropped line showing. Only the payee’s own default stops the job: if it is missing, the journal fails with MISSING_DEFAULT_GL_CODE and the code it wanted.

The journal’s description is the voucher’s Description, its remarks are the voucher’s Remarks, and its reference is the voucher’s Reference. The exchange difference on a foreign-currency payment is not part of this journal: it is a separate journal (FOREX_GAIN / FOREX_LOSS) written for each contra when the contra is saved.

What FINAL does, continued:

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 voucher is FINAL with its cashbook line and journal and no contra. A contra keyed on a draft voucher is live as soon as the draft is saved. The listing’s bulk FINAL fires the same request, and it sends whatever unsent Contra-tab rows the screen still holds — including rows keyed on the last voucher you opened and left without saving, until you press + or open another voucher, which replaces them. How to spot it: after a bulk FINAL from the listing, open the voucher you last had open and check its Contra tab for knock-offs you did not mean to keep.
5. If the voucher carries intercompany data, the background job creates the mirror or queues it for Process (Intercompany). FINAL queues no webhook and no e-mail for a payment voucher; SEND EMAIL is on demand.

Saving a change to the amount of a finalised payment 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, where Reference and Remarks stay editable, every save re-synchronises the voucher’s cashbook lines with its payment 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 voucher 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 Settlement Adjustment is not refused, and it unreconciles. It rewrites the payment lines directly, 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, so a voucher that once failed to post after writing its journal ends up with two — 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 voucher’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 supplier invoices become outstanding again. It is available on any FINAL voucher (no e-Invoice lock on payment vouchers). See What a void undoes.

Where each figure comes from

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

• The cashbook line — on the voucher’s Trace Document › 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 payment line, in the cashbook named on that line’s settlement method, at the payment less the method’s charges, as money out, dated the voucher’s date, carrying the payment line’s Reference and Remarks, and naming the payee from the Account tab’s billing name before the entity’s own name. A later save re-synchronises it (above).
• The journal — written by its own job, which reads the company default GL codes and the payee’s AR/AP type as they stand when it runs. The type comes from the payee’s link to the voucher’s company first and from the entity’s own type otherwise, so one person can be a trade creditor to GS and an employee payable to GSO; changing the type changes the next voucher that posts, and a re-post. What the journal contains.
• The outstanding balance of the voucher and of each invoice it paid — stored on each document and rewritten inside the knock-off request itself: the document’s opening figure plus every knock-off against it. This is the balance the creditor reports 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 payment lines — which a knock-off 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, payables included. A knock-off keyed or deleted on this voucher’s Contra tab works both documents’ stored months out again, counting the knock-off only in months ending on or after its contra date. Changing a knock-off’s date in place does not. So: pay a March invoice from your accessory wholesaler with a voucher dated 31 March, key the voucher on 3 April with the settings as they come, and the knock-off is dated 3 April — March’s stored month still shows the invoice open, with the voucher beside it as a payment not yet applied. The supplier’s total for March is right; only the listing surprises you. 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 (Settlement 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.

Correcting expense lines after FINAL: what an adjustment re-posts

A finalised voucher that paid the right payee the right amount, but booked it to the wrong expense, does not need a void. Expenses Adjustment rewrites the voucher’s expense lines and posts its journal again. Suppose GadgetSphere paid a contractor RM 1,200 from GS-KV-01 and booked it all to EXPENSE-MARKETING, when RM 400 of it was shop-fit work that belongs in EXPENSE-RENTAL. On the voucher’s Expenses Adjustment tab you remove the line, add two GL-code lines of RM 800 and RM 400, and press ADJUST EXPENSES.

What happens behind the screen:

• The request is kept, then a job runs at once. The adjustment stores the expense lines as they were and as you want them. A job then changes the lines on the voucher, reverses the voucher’s journal in full and posts a new one from the corrected voucher. Whether it reverses first is decided by the voucher’s journal flag, not by whether a journal exists: a voucher flagged posted is reversed and re-posted; a voucher with any other flag simply gets a new journal, with no reversal and no look for one already there. A voucher whose posting once failed after the journal was written — a journal exists while the flag reads failed or nothing — therefore ends the adjustment with two live journals and nothing reverses the first. Open Trace Document on the voucher and read the journal flag before adjusting one that ever failed to post. The Expenses Adjustment menu lists every adjustment with its status (Processed or Failed), whether the lines were updated, and the error when they were not. An adjustment identical to the voucher fails with No changes have been made to the expenses.
• The correction lands in the voucher’s own month. The reversal and the new journal both carry the voucher’s transaction date; only their posting date is today. Correcting a March voucher in May changes March’s expense accounts, after March may have been reported.
• The payments are not touched. Payment lines, their cashbook entries and any bank reconciliation stay as they were. Only expense lines booked to a GL code change; item lines are left alone.
• The payee’s account takes any difference. The payee line of the journal is whatever makes the journal balance. If the new lines add up to what the old ones did, the payee line is unchanged. Type RM 380 instead of RM 400 and the new journal carries RM 1,180 of expenses against RM 1,200 paid, so RM 20 is debited to the contractor’s account — a balance nobody meant to create, and nothing on the screen points it out.
• A new line carries no tax and no department tag. Lines added here have no tax amount, so replacing an expense line that carried SST input tax drops the tax from the journal, and the tax lands on the payee’s account the same way. A blank tag on the line takes the voucher header’s when the journal posts (how tags fall back).
• An amount changed in place is not carried. Deleting a line and adding one reach the voucher. Saving a new amount on an existing line does not reach the adjustment: the edit builds the changed line without the identity that would match it to the voucher’s line.

What it will not do: keep count of its own journals. After one adjustment the voucher has three — the original, its reversal and the new one. A second adjustment, or a VOID after an adjustment, reverses whichever of the three the database returns first, not necessarily the latest, so it can undo the original a second time and leave the voucher’s journals adding up to something other than its lines. Nothing reports it.

Noticing is a person’s job. An adjustment is a correction to a posted month made from outside the month, so the check belongs to whoever closes the books. The Expenses Adjustment menu is the list of every one of them, with who made it and when. For a voucher adjusted more than once, or voided after an adjustment, the voucher’s Trace Document › Journal Txn grid shows every journal line with its journal number: the lines should net to the voucher’s current expense lines against its payments, and a payee line that should not be there is the RM 20 above.

Paying a staff claim on this voucher

A claim posts nothing and creates no voucher. A claim line approved for Finance Payment lands in its company’s claim cycle for the month; finance reviews it there, and the cycle’s PV Details Report lists each line with its claim item’s GL code and tax. That report is the working paper for this voucher. Lines set to Salary Payment go to payroll instead and never reach this applet.

Say the GS-KV-01 supervisor’s RM 280 March mileage had been set to Finance Payment rather than paid with salary. You raise one voucher on her own employee record: one expense line on the GL code the report shows for mileage, RM 280, and one payment line of RM 280 on the bank method behind CASH-PRI-KV01. Expenses equal the payment, so the journal is Dr mileage RM 280, Cr bank RM 280, with no payee line — her AR/AP type does not matter. FINAL writes one RM 280 cashbook line dated on the voucher, which is what the transfer on the bank statement is matched against.

Three ways it goes wrong:

• The payment and the lines differ. Pay RM 280 against both her lines (RM 280 and RM 64) and RM 64 is credited to her account. An employee created in Employee Maintenance has the employee payable type, and that account is the company’s Employee Payable default: if the company has never mapped it, the voucher is FINAL, the cashbook line posts, and there is no journal. An employee record left at the trade-debtor type takes the balance to trade debtors instead, and she appears on the debtor statement.
• The receipt carried tax. Put it on the expense line here; it posts to the input-tax default on its own line. That is why a taxed claim is paid on this voucher and not on the Reimbursement Payment Voucher, whose journal fails on a taxed line.
• The voucher’s date decides the month. The journal takes the voucher’s date, so a March claim paid on a voucher dated 5 April is an April expense.

Nothing marks the claim paid when this voucher goes FINAL; a claim line has no paid status. The tie between the two is the PV Details Report you worked from, so keep it with the voucher as an attachment.

The salary batch: two shapes, and what each costs

Payroll’s net pay can reach the bank two ways, and only one of them uses this voucher. Both are correct accounting. Which one you use is your accountant’s decision; BigLedger has not named a house answer.

• The payroll journal credits the bank directly. One document a month. A journal writes no cashbook line, so the salary debit on the bank statement never has a line to match, and whoever reconciles explains the same unmatched line every month.
• The journal credits a net-pay payable, and one voucher here pays it on pay day, with one expense line coded to the payable account and a payment line on the paying bank’s method. Expenses equal the payment, so there is no payee line; the voucher writes the cashbook line Bank Reconciliation matches and returns the payable to nil. The cost is a second document each month. The benefit: a payable that is not nil after pay day tells you the transfer was never recorded.

Both shapes from the payroll side.

A payment’s three people: who approves, who pays, who ties out

The applet records a payment; it does not decide one, and it does not move money. Three jobs stay with people.

• Approving. There is no approval step here, and SEND EMAIL is not one. The person who approves a supplier payment checks it against the invoice and the delivery before anybody presses FINAL; a staff claim arrives already approved through the claim’s own chain and the cycle’s review. The control this applet gives you is who may press FINAL: hide the button and grant its permission to the approver, so the clerk who keys a voucher is not the person who finalises it. The button is a screen control — a voucher finalised through the API is not held to it.
• Paying. The money leaves through your bank’s portal or a cheque, outside BigLedger; File Export produces a CSV for the bank. Date the voucher on the day the money leaves, because every figure above takes the voucher’s date.
• Tying out. The person who matches the bank pairs each voucher’s cashbook line with the bank’s own line; whoever looks after payables compares each supplier’s own account of what you owe with the Creditor Report after the month’s payments.

Paying with a difference. A voucher whose expense lines and knock-offs do not add up to its payment posts the difference to the payee’s account — a supplier paid RM 18.00 short because of a disputed line, a claim paid RM 64 less than its lines. Two ways to handle it, and the choice is your group’s policy, not the software’s: finalise and leave the difference visible on the invoice or the payee’s account until a credit note, a second payment or a write-off clears it (an open item somebody has to own), or hold the voucher until the person who approves payments rules on it (the cash has usually already left, so the cashbook is behind the bank until FINAL).

How you know a payment run is done

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

1. Every voucher of the run is FINAL, and its Trace Document shows a Cashbook Txn line for each payment line — the amount less any method charges, on the voucher’s date — and a Journal Txn grid with no payee line you did not mean.
2. In Query Cashbook Transaction for the paying cashbook, the day’s lines add up to what left the bank that day.
3. Each supplier invoice you paid shows its outstanding reduced by exactly the knock-off, on the Creditor Report’s outstanding listing; for staff, the Finance Payment total on the cycle’s PV Details Report equals the vouchers you raised, and Employee Payable is nil unless you meant to leave a balance.

Until every difference is named to a voucher, the run is not done, however small the difference.

Related applets

• Purchase Invoice (Internal), Purchase Debit Note (Internal), Purchase Credit Note (Internal) — the documents a payment is applied to.
• Receipt Voucher (Internal) — the inbound twin; identical settlement, contra and adjustment mechanics.
• Reimbursement Payment Voucher (Internal) — the same form for paying a person back rather than a supplier. Unlike this applet it raises no creditor control line and no tax line.
• Cashbook Applet — settlement methods and their GL codes.
• Bank Reconciliation — matches the cashbook lines this voucher writes. A match guards only the line’s amount: a later save, a Settlement Adjustment or a VOID can still move or remove a matched line (see Lifecycle and effects).
• Claim Cycle — its PV Details Report is what a staff-claim voucher is keyed from.
• Supplier Applet — the payee’s AP type decides the creditor account.
• Chart of Account Applet, Organisation Applet — default GL codes, branches, numbering.
• Ledger And Journal, Creditor Report, Statement of Account — where the posting is reviewed.

Troubleshooting

Related documentation

• Standard procurement workflow — where the payment closes the loop
• Bank reconciliation guide
• The aging still shows an invoice already paid — stored months and the knock-off date
• HR and payroll related applets — staff vouchers, the employee’s AR/AP type, the salary batch
• Financial Accounting module and Purchasing module