Billing Configuration

Three small master lists that sit behind the billing workflows: the Charge Types that categorise money AIR levies on a customer, the Discount Reasons behind every post-approval discount, and the Dishonour Reasons recorded when a payment bounces. Each is a straightforward create/edit lookup — but two of them also carry the accounting settings that decide whether a workflow automatically posts to the ledger.

Built — all three master screens are live in the console.

Permissions

Each list has a view gate and a manage gate. Viewing needs charge_type.view, pad_reason.view or payment_dishonour_reason.view; creating, editing or deleting needs the matching charge_type.manage, pad_reason.manage or payment_dishonour_reason.manage. The super-admin role bypasses all of these.

Why these are separate from the workflows

The Charges, Post-Approval Discounts and Payment Voucher screens all use these lists but do not let you edit them — you pick a charge type, a discount reason or a dishonour reason from a dropdown there. This page is where those dropdown options are defined. Keeping them here means an admin can add a new charge type or retune a discount reason's accounting without a code change.

Charge Types Built

Nav: Billing → Charge type. A charge type classifies money AIR levies on a customer — a cheque-bounce fee, a re-despatch cost, a general adjustment. When a Charge is raised, it points at one of these types, which supplies the default rate, the notification preferences, and (optionally) the accounting treatment.

Fields

Field	Type	Notes
Code	Text (≤50)	Unique short identifier, e.g. CHEQUE_BOUNCE.
Name	Text	Human-readable label shown in charge dropdowns.
Category	Select	One of Payment, Sale order or General — groups the type by what it relates to.
Default rate	Number (₹)	The amount pre-filled when a charge of this type is raised. Zero is allowed.
Notify SMS / Notify email	Toggles	Whether raising a charge of this type notifies the customer over that channel. Drive the customer-facing charge notifications.
Notes	Textarea	Free-text internal note.
Active	Toggle	Inactive types are hidden from the charge dropdowns but keep their history.

The Accounting section

The form's second section decides whether resolving a charge of this type as a Levy also posts a balanced entry to the ledger. It is collapsed to a single toggle until you turn posting on.

Field	Type	Notes
Create journal entry	Toggle	Off by default. When on, levying a charge of this type posts a double-entry to the ledger. The two account fields below appear only when this is on.
Debit account	Text (≤50)	The account code debited by the posting.
Credit account	Text (≤50)	The account code credited by the posting.

Both accounts are required for a posting to happen

If Create journal entry is on but either account code is left blank, nothing is posted — the levy still goes through, just without a ledger entry. There is no chart-of-accounts picker; the account codes are free text, so type the exact codes your accounting team uses. See Charges for the levy workflow and Accounting for where the resulting entry appears.

Screenshot placeholderThe Charge Type edit form — the two sections "Charge Type" and "Accounting", with the debit/credit account fields revealed after Create journal entry is toggled on.

Discount Reasons Built

Nav: Billing → Discount reason. Every Post-Approval Discount (PAD) is booked against a reason. The reason decides where the discount's partner (customer) comes from and — like charge types — whether approving the discount posts to the ledger.

Fields

Field	Type	Notes
Code / Name	Text	Unique code + label shown in the PAD reason dropdown.
Description	Textarea	Free-text explanation of when to use this reason.
Partner source	Select	Where the ledger partner comes from: From reason, From SO (the sale order's customer — the default) or Custom.
Impact on expense	Toggle	Marks whether this discount is treated as an expense — used by downstream reporting.
Active	Toggle	Inactive reasons drop out of the PAD dropdown.

The Accounting section

Identical in shape to charge types, but here the posting fires when a PAD with this reason is approved. Note the default differs: Create journal entry is on by default for discount reasons (most discounts are meant to post).

Field	Type	Notes
Create journal entry	Toggle	On by default. When on (and both accounts set), approving a PAD with this reason posts a balanced entry and advances the PAD straight to Posted.
Debit account / Credit account	Text (≤50)	The account codes for the posting. Blank ⇒ no entry, exactly as with charge types.

The PAD workflow and its "why Cancel can be refused once Posted" behaviour are covered on the Discounts, Refunds & Charges page.

Dishonour Reasons Built

Nav: Billing → Dishonour reason. When a deposited Payment Voucher bounces, the dishonour records one of these reasons. This is the simplest of the three masters — no accounting section (the reversal's accounts live in System Configuration under the bounced.* keys, not on the reason).

Fields

Field	Type	Notes
Code / Name	Text	Unique code + label, e.g. INSUFFICIENT_FUNDS.
Responsibility	Select	Who the bounce is attributed to: Customer or Bank.
Active	Toggle	Inactive reasons are hidden from the dishonour dropdown.

The dishonour reversal posting is configured elsewhere

Unlike charge types and discount reasons, the choice of whether a bounce posts a reversal to the ledger is a global setting, not a per-reason one — a bounce reverses the same way regardless of why it bounced. Turn it on and set its accounts via the bounced.create_journal_entry, bounced.debit_account and bounced.credit_account keys on the System Configuration page. See Payment Vouchers for the dishonour workflow.

Creating and editing a master row

All three lists behave the same way:

Open the list
Pick the master from the Billing navigation group. You need the relevant *.view permission.
Create or edit
Use New to add a row, or the row's Edit action to change one. Both need the *.manage permission.
Deactivate instead of delete where possible
Turning Active off removes a type or reason from its dropdown while keeping every record that already used it intact. Deleting a row that is still referenced by existing charges, discounts or vouchers is refused at the database level, so prefer deactivation.