Payment Vouchers
A payment voucher records money received from a customer — cash in the field, a cheque, a bank transfer, or a gateway payment. This page covers the Payment Vouchers list, its 10-state lifecycle, and the two actions the console lets you drive: Approve and Cancel.
You cannot create a payment voucher from this console — there is no New voucher button. Vouchers are created by the Sales-Executive field app when an SE collects money, by the public API, or automatically by the payment-gateway webhook (Razorpay/CCAvenue) and bank-statement reconciliation described on the Bank Reconciliation page. The HO console's job is to review each voucher and approve or cancel it — not to originate it.
The Payment Vouchers list
Nav: Billing → Payment Vouchers. Permission required to view the list: payment.view. There is no create or edit form — vouchers are originated elsewhere (see above) — but each row can be opened to a read-only detail view (below); every action still happens directly from the row.
| Column | Shows |
|---|---|
voucher_number | The voucher's reference number. Shown as a badge, searchable and sortable. |
| Customer | The paying customer's name (customer.user.profile.full_name). |
| Amount | The amount received, formatted in ₹ (amount), sortable. |
| Payment method | Badge showing how the money arrived — see the full list of methods below. |
| Company | Badge showing which AIR group company the voucher belongs to: Air, Ais, Ainfo, or Ala. |
| State | The voucher's current lifecycle state — badge, coloured as in the diagram below. |
procuring_date | The date the money was actually collected/received, sortable. |
Payment methods (payment_method, shown as a plain badge with no colour map): Cash, Cheque, DD, NEFT, RTGS, IMPS, Razorpay, CCAvenue, VPP, Wallet, QR.
Filters
| Filter | Narrows by |
|---|---|
| State | Any of the 10 PaymentVoucherState values (see the diagram below). |
| Payment method | Any of the 11 payment methods listed above. |
Viewing a voucher Built
Use the View row action to open a voucher's detail page — read-only, gated by the same payment.view permission as the list. It has five info panels plus three child tables:
- Voucher — the voucher number, the current state (same coloured badge as the list), the customer, the company, the payment method and the procuring date.
- Amounts — the amount received, in Rupees.
- Collection & approval — who collected the payment, who approved it, and the approval date.
- Dishonour — the dishonour reason and date, populated only if the voucher was later dishonoured.
- Linked records — the journal entry the voucher posted (if any), the despatch package it is tied to, and the bank statement line it reconciled against.
Below the panels, three read-only tables: Allocations (how the voucher's amount is split across sale-order lines), Account allocations (any cross-customer or account-level allocation), and Recoveries (recovery records raised against this voucher after a dishonour). Everything here is read-only — a voucher is driven through its lifecycle by the Approve / Cancel actions and the dishonour flow, not edited as a form.
The voucher lifecycle
A voucher moves through up to 10 states. The console lets you drive exactly two transitions — Approve and Cancel — shown as solid amber arrows below. Every other transition (dashed grey) happens through the field app, the public API, an automated job, or the bank-reconciliation flow covered on the next page.
Approve Built
Confirms that HO has reviewed and accepted an allocated voucher. Visible only on vouchers in state Allocated.
- Find an Allocated voucher
Filter the list by State = Allocated, or scan for the Approve button on a row — it only appears in this state.
- Select Approve
Icon: check-badge, colour success.
- Add remarks (optional)
A
remarkstextarea opens — up to 500 characters. It is not required; leave it blank if there is nothing to note. - Confirm
A confirmation dialog asks you to confirm the approval before it proceeds.
- Result
The voucher's state changes to Approved and the Approve button disappears — there is nothing left to approve.
Cancel Built
Cancels a voucher outright. Visible only on vouchers in state Draft, Submitted or Dishonoured.
- Find a cancellable voucher
Filter by State = Draft, Submitted or Dishonoured.
- Select Cancel
Icon: x-circle, colour danger.
- Add remarks (optional)
Same
remarkstextarea as Approve — optional, up to 500 characters. - Confirm
A confirmation dialog asks you to confirm before proceeding.
- Result
The voucher moves to Cancelled and any existing allocations and account-allocations against it are deleted.
Cancelling a voucher removes any record of it being allocated against a customer's outstanding orders. Only cancel a voucher you are sure is invalid — for example, a duplicate entry or a payment that will never actually clear.
Behind the scenes, the service that powers Cancel also allows cancelling from Suspense. This path is used internally by bank reconciliation's auto-match (it cancels a duplicate suspense voucher once a real match is found) — it is not something you trigger from a button here. See Bank Reconciliation.
What is a Suspense voucher?
A Suspense voucher records money that has definitely arrived — for example, a bank credit or a gateway settlement — but that has not yet been matched to a specific customer. It sits apart from the main Draft→Cleared chain: it isn't created by moving a Draft voucher forward, and it doesn't automatically progress on its own. Bank reconciliation's auto-match works through unmatched bank-statement lines and, where it finds a genuine match, clears the correct voucher and cancels any duplicate suspense voucher left over. See Bank Reconciliation for the full matching flow.
Transitions not in this console Planned / elsewhere
The following state changes are real parts of the voucher lifecycle, but none of them have a button on this list. They happen through the field app, the public API, or automatically:
| Transition | Driven by |
|---|---|
| Submit (Draft → Submitted) | Field app / API, when an SE submits collected money. |
| Allocate (Submitted → Allocated) | Field app / API, allocating the payment against a customer's orders. |
| Deposit (Approved → Deposited) | API, when the voucher's money is physically banked. |
| Clear (Deposited → Cleared) | Usually automatic — bank reconciliation's auto-match clears a voucher once its bank-statement line is matched. See Bank Reconciliation. |
| Dishonour (Deposited → Dishonoured) | API, when a cheque or instrument bounces. |
| Hold (→ On Hold) | API. |
| Reallocate / account-allocate | API — re-targets an existing allocation, e.g. moving a suspense voucher onto the correct customer once identified. |
When a deposited voucher is dishonoured, the payment that was expected to clear is reversed: the customer's balance is re-opened (they owe again) and the bank/cash that never cleared is credited back. If bounced-payment accounting is switched on in System Configuration — an opt-in flag plus a debit and a credit account under the accounting group (the bounced.* keys) — then dishonouring a voucher also creates and posts a balanced double-entry to the ledger in the same step, linked back to the voucher. If the flag is off or either account is blank, nothing is posted; the dishonour itself still goes through. The entry, once posted, appears on the Accounting — Journal & GST page. (This is separate from any cheque-bounce Charge raised against the customer.)
See also
- Bank Reconciliation — how bank-statement lines get matched to vouchers, including the automatic Clear step.
- Discounts, Refunds & Charges — post-approval discounts, customer refunds and charges, which sit alongside payments in the Billing group.
- Accounting — journal entries and GST e-invoices, the ledger side of billing.