Every payment that leaves a Nepal business should pass through a defined authorization gate. In practice, most do not. The gate exists - it is usually the owner or a trusted senior person - but there is no documented rule about what they are authorizing, no record that they authorized it, and no control that prevents a payment from moving without their approval when they are unavailable or distracted.
A financial authorization matrix defines exactly who can approve what, up to which amount, and under what conditions. It replaces the informal understanding of "check with the boss before any big payment" with a structured set of rules that the accounting system enforces automatically. The result is not less trust - it is a system that protects the business precisely because it does not rely on trust alone.
This article walks through how to design a four-level authorization matrix for a Nepal mid-size business, what to include for payment approvals and supplier transactions, and how to handle authorization when the primary approver is unavailable - without stopping the business.
What a Financial Authorization Matrix Is and Why It Matters
An authorization matrix is a documented table that maps transaction types and amounts to the minimum approval authority required. It answers two questions for every financial transaction: who is authorized to approve it, and at what amount does it need to go higher. Without this mapping, authorization decisions are made informally - whoever is available, whoever the accountant usually calls, whoever happens to be in the office that day.
The matrix below is a practical starting point for a Nepal mid-size business with a turnover between NPR 5 crore and NPR 50 crore. Adjust the thresholds to match your actual transaction patterns - the principle matters more than the specific amounts.
| Level | Role | Upper Limit | Transaction Types |
|---|---|---|---|
| Level 1 | Staff / Requestor | NPR 5,000 | Petty cash, stationery, minor office expenses |
| Level 2 | Department Head | NPR 50,000 | Routine purchases, utility payments, team expenses |
| Level 3 | Finance Manager | NPR 5,00,000 | Vendor payments, procurement, payroll processing, intercompany |
| Level 4 | Director / Owner | Above NPR 5,00,000 | Capital expenditure, bank transfers, unusual payments, new vendor first payment |
Notice that the matrix assigns Level 4 authority to any new vendor's first payment regardless of amount. This is a practical Nepal-specific addition: the highest proportion of fictitious vendor payments occurs on the first transaction, before a vendor relationship has been verified through multiple cycles.
A financial authorization matrix is not a bureaucracy tool - it is a business protection tool. It tells everyone in the organization exactly what decisions they are empowered to make, and it removes the ambiguity that causes both delays and control failures.
Designing Approval Levels for Your Nepal Business
The thresholds in your matrix should reflect where the real financial risk sits in your business, not a theoretical standard. For a construction company with NPR 20 crore annual turnover, a Level 3 limit of NPR 5 lakh might be too low - routine material purchases for a single site can exceed that. For a professional services firm where no single transaction normally exceeds NPR 2 lakh, the Level 2 and Level 3 thresholds should compress accordingly.
Beyond amounts, transaction categories add another dimension to the matrix. Capital expenditure - machinery, vehicles, computers, land - warrants higher authority than operational spending of the same amount, because capital decisions have longer consequences and are harder to reverse. Foreign currency transactions, wire transfers to overseas accounts, and payments to related parties similarly deserve elevated approval requirements regardless of amount.
The Memorandum of Association (MoA) of every company registered under the Nepal Company Act 2063 typically includes provisions for financial authority limits of directors and officers. Many Nepal companies have these limits in the MoA document but no corresponding control in the accounting system - the authorization exists on paper, the system does not enforce it. An IRD audit or a statutory audit will ask who authorized specific payments. The authorization matrix gives you a documented answer that goes beyond "the owner approved it verbally."
One commonly missed category in Nepal business matrices is payment to connected parties - owner-linked vendors, family business suppliers, related company intercompany transfers. These transactions carry the highest reputational and tax risk (transfer pricing rules under the Income Tax Act 2058 apply to related-party transactions) and should require at least one level of approval above what an arm's-length transaction of the same size would need.
Set your thresholds based on the actual size and risk profile of your transactions - not a template. Review the matrix once a year and adjust for growth. A business that doubled revenue last year probably needs different thresholds than it did at the start.
Payment Authorization for Supplier Transactions
Supplier payments are where the authorization matrix has the most direct financial impact. The payment cycle for a supplier typically runs: purchase order raised, goods or services received, invoice received, payment voucher prepared, payment released. Each of these steps represents a control point. The authorization matrix governs the payment release step - but a well-designed system also requires authorization at the purchase order stage, before the liability is even created.
In practice, this means a supplier payment above NPR 5 lakh should require documented evidence that: the purchase order was authorized at the correct level, the goods or services were actually received (GRN or service confirmation), the invoice matches the PO in amount and vendor, and the payment voucher has been reviewed and approved. Without this chain, a payment can be processed for goods that never arrived, at a price different from what was agreed, or to a vendor account that has been changed between the original registration and the payment date.
The single most important control in payment authorization: the person who approves a payment should never be the same person who executes the bank transfer. In a team of two or three finance staff, this separation is possible and essential. If both roles currently sit with one person, the first change to make before any other control is separating payment approval from payment execution.
Nepal's banking system adds one more practical dimension. Bank transfers above certain thresholds may require secondary authentication through the bank's own portal (eSewa Business, ConnectIPS for corporate accounts, bank internet banking with two-factor authentication). These banking-side controls complement your internal authorization matrix but do not replace it - banking authentication confirms that the transfer instruction came from an authorized device, not that the underlying transaction was legitimately approved through your business process.
Effective payment authorization requires control at both ends of the cycle: purchase authorization before the liability is created, and payment authorization before cash leaves the account. Controlling only the payment step means the commitment was already made without oversight.
Emergency Authorization and the Audit Trail
Every authorization matrix needs a documented answer to one question: what happens when the required approver is unavailable and a payment is urgent? Without a defined answer, the business will make one up in the moment - and those improvised decisions are where control failures happen. The most common improvised answer in Nepal businesses is "the owner verbally approved it, we will get the signature later." Later often never comes, and the audit trail shows an unauthorized payment.
Emergency authorization should work through delegation, not exception. The matrix should specify a backup approver for each role, and a process for activating that backup - not an override that skips authorization entirely. In practice: if the Finance Manager is ill, the Director activates the Department Head as acting Finance Manager for the duration, and the ERP reflects that delegation. Payments approved during that period carry the acting authorization on record, not a gap.
The audit trail is the evidence that proper authorization was obtained, even when everything went right. Every authorization event should record: who approved, at what time, from which device or location, what they saw before approving (the transaction detail as it existed at approval time), and any comment they added. This record protects the business during an IRD assessment, a statutory audit, or a dispute with a vendor. It also protects individual approvers - the record shows exactly what information was in front of them when they made the decision, which matters if a payment later turns out to be fraudulent and questions arise about due diligence.
The audit trail does not just record that authorization happened - it records what the approver knew when they decided. This is the document that defends the business and the approver if a payment is later questioned. A system that can produce this record on demand is categorically different from one that cannot.
All financial authority concentrated in one person regardless of transaction size or type
Routine transactions approved at the correct level without bottlenecking senior management
Verbal approvals, WhatsApp messages, paper signatures with no searchable audit log
Who approved, when, from where, what information they saw - permanently attached to the transaction
Vendor payments wait, staff holds, purchases stall whenever the one approver is unreachable
Full transaction detail delivered to approver's phone - reviewed, commented, and approved in minutes
Urgent payments miss deadlines because there is no defined fallback when the approver does not respond
Unactioned approvals route to the next level automatically after the defined period expires
No separation between the decision to pay and the act of transferring funds
Finance manager approves, accounts staff executes transfer - two distinct steps, two distinct audit events
Frequently Asked Questions
Set limits based on your current transaction profile and review them annually, or when a significant structural change happens - a new branch, a new product category, a major supplier relationship. Growth typically raises all thresholds over time. A business processing NPR 2 crore in vendor payments per month needs different limits than one processing NPR 20 lakh. The ERP makes updating limits straightforward - it is a configuration change, not a technical project.
Document them first. Talk to the people involved, understand what they currently approve and why, and translate those informal arrangements into the formal matrix. In most cases, the informal system approximates what the matrix should be - the problem is that it is undocumented and therefore unenforceable and unauditable. Formalizing it does not change who approves what; it just makes that arrangement official, consistent, and verifiable.
It applies to every transaction with financial consequences: purchase orders, expense claims, credit notes, write-offs, stock adjustments, journal entries above a threshold, and intercompany transfers. The matrix in this article uses supplier payments as the example because that is where the most immediate cash risk sits. But a credit note issued without authorization reduces receivables just as a payment reduces cash. Extend your matrix to cover the full range of transactions that can move money or reduce assets.
Authorization Matrix Built Into Every Financial Transaction
MISAC's approval system is not a separate module bolted onto the accounting system - it is built into the transaction layer. Every voucher type (payment, receipt, purchase order, journal, GRN) passes through the configured authorization chain before it can be posted. A payment voucher above the Finance Manager's limit cannot be saved as posted until the Director has approved it. The system does not route around the rule because someone is in a hurry or because the vendor is calling.
For the Director or Finance Manager away from the office, MISAC delivers approval requests to the mobile app with the full voucher detail - vendor name, amount, payment account, line items, and any attachments such as the vendor invoice scan. They review, comment, and approve or reject from their phone. The decision is timestamped to the second, attributed to their login, and permanently attached to the voucher. If they are in a meeting and cannot respond within the configured window, the escalation rule fires and the backup approver receives the task automatically.
The businesses MISAC Intelligence Pvt. Ltd. works with often find that implementing the authorization matrix surfaces patterns they were not previously aware of - clusters of payments that consistently come in just below a threshold, vendors that appear for the first time only on large payments, approval sequences that short-circuit in predictable ways. The matrix does not create those patterns; it makes them visible for the first time.
Ready to See MISAC in Action?
Discuss how to configure a financial authorization matrix for your specific business structure and transaction profile.