In most Nepali trading companies, the purchase cycle works like this: a warehouse manager sends a WhatsApp message to the owner saying stock is running low. The owner calls a supplier and places an order verbally. The supplier delivers goods and sends an invoice. The accountant enters the invoice into the accounting system and pays it. No purchase order was ever created. No one confirmed the quantity and price before delivery. No one checked whether what arrived matched what was ordered. And if a dispute arises six months later about what was agreed, there is no document to refer to.
This informal purchase process works at small scale because relationships substitute for documentation. The owner knows the supplier. The supplier knows the business. Disputes are rare, and when they occur they are resolved through trust rather than records. But as a business grows - more staff placing orders, more suppliers, more transactions, more cash at stake - the absence of process becomes expensive. Duplicate orders. Overpayment on short deliveries. No way to track what was ordered versus what arrived versus what was invoiced. And no audit trail when something goes wrong.
Purchase order software Nepal businesses need automates the full cycle from the moment a stock need is identified to the moment the supplier is paid. Each step connects to the next. Every decision is documented. Every discrepancy is visible. And the accounting entries post automatically from the goods receipt and the invoice match - no separate posting, no re-entry by the accountant.
Raise a Purchase Requisition
The purchase cycle starts when someone in the business identifies a need. In an automated system, this need is captured as a purchase requisition - a formal request that specifies the item, the quantity required, the urgency, and the reason for the purchase. The requisition is raised by the warehouse manager, the project manager, or any staff member with requisition rights. It is not a purchase order - it is a request for authorisation to purchase. The person raising the requisition selects the item from the inventory master, which auto-populates the last purchase price, the current stock level, and the reorder threshold. This context makes it easier for the approver to assess whether the requisition is justified or whether existing stock can serve the need. Requisitions that are not approved do not proceed to purchase order - creating the first control point in a process that previously had none.
Approve and Issue the Purchase Order
The approved requisition converts to a purchase order with one action. The purchase order specifies: supplier name, delivery address, item details, quantities, agreed price, and expected delivery date. It carries a sequential PO number that the supplier should reference on their invoice. Before issuing, the approver can review the supplier's last price (from the purchase history), compare it to the requisition price, and adjust if negotiation is needed. The issued PO is sent to the supplier directly from the system - printed or emailed - and a copy is logged against the supplier's record. From this point, the business has a documented commitment to purchase at a specific price and quantity, which is the document that resolves disputes about what was ordered and what was agreed.
Import-heavy businesses in Nepal working with Indian or Chinese suppliers frequently use LC (Letter of Credit) based purchases. The purchase order in these cases must reference the LC number, the port of entry, the expected customs clearance date, and any advance payment made against the order. Custom fields on the PO form allow all of these Nepal-specific data points to be captured on the PO document - so the PO, the LC documentation, and the eventual GRN are all linked by the same reference number throughout the procurement cycle. Advance payment against a PO is recorded as a payment voucher linked to the PO, so when the invoice arrives, the advance is visible and the net payable amount is calculated correctly.
Record Goods Receipt - GRN
When goods arrive, the warehouse team records a Goods Receipt Note (GRN) against the purchase order. The GRN screen pulls the open PO lines automatically - the warehouse team enters only the quantities actually received. If the supplier delivered 80 units of 100 ordered, the GRN records 80. The 20 outstanding units remain open on the PO for a subsequent delivery. The GRN automatically updates inventory: the 80 units add to stock at the price specified on the PO. An accounting entry posts simultaneously: debit inventory, credit goods receipt clearing. No separate accounting step. The warehouse manager does not need to call the accountant to update the books - the GRN action does it.
Partial deliveries are one of the most common sources of procurement errors in Nepali businesses. A supplier delivers 80 of 100 units ordered and invoices for 100. Without a GRN that records what actually arrived, the accounts team has no way to know the delivery was short. They see the invoice, match it against the PO (which was for 100), and pay for 100. The short delivery becomes a supplier credit that the business may never recover. A GRN-based receiving process makes partial deliveries visible immediately - the system shows what was ordered, what has been received to date, and what remains outstanding before any payment can be released.
Match Supplier Invoice to PO and GRN
When the supplier's invoice arrives, it is entered into the system and linked to the purchase order and the GRN. The system compares three quantities: the PO quantity (what was ordered), the GRN quantity (what was received), and the invoice quantity (what the supplier is billing for). If all three match within the configured tolerance, the invoice is cleared for payment. If the supplier invoices 100 units when only 80 were received, the system flags a discrepancy and holds the invoice from the payment queue until it is resolved. Resolution options include: requesting a credit note from the supplier for the undelivered units, waiting for the outstanding delivery before clearing the invoice, or approving a partial payment for the received quantity. Each resolution option is documented and approved, not resolved informally.
Release Supplier Payment
Once the invoice is matched and approved, it appears in the accounts payable queue for payment. Payment terms on the supplier's record determine when the invoice becomes due - the system can be configured to remind the accounts team of upcoming payment dates so that discount windows are not missed and credit terms are honoured. The payment voucher links to the invoice being settled. If an advance was paid against the PO in step two, the system shows the advance as a credit against the invoice, and only the net balance requires payment. The payment posts automatically to the bank account from which it is made, reduces the accounts payable balance, and closes the invoice. The full cycle - from requisition to payment - is documented end to end, with every action logged by user and timestamp.
The five-step automated purchase cycle - requisition, PO, GRN, invoice match, payment - creates a documented, auditable trail from need identification to payment. Every discrepancy between what was ordered, what arrived, and what was invoiced is visible before payment is released. This single control eliminates the most common cause of procurement losses in Nepali businesses: paying for goods that were not received.
Purchases placed by phone or WhatsApp with no written record of what was ordered, at what price, or from which supplier branch.
Every purchase starts with an approved requisition that converts to a PO. Quantity, price, and delivery terms are recorded before goods are ordered.
Goods arrive and are stacked in the warehouse. No formal record of what was received, when, or by whom - until the accountant enters the supplier invoice.
Warehouse records received quantities on GRN. Inventory updates immediately. Partial deliveries are visible. The accounting entry posts automatically.
Supplier invoices entered and paid based on the invoice amount alone - no check against what was ordered or what arrived.
Invoice quantity checked against PO and GRN automatically. Discrepancies hold the invoice for resolution before any payment is released.
Cash advances paid to suppliers before delivery recorded as general expenses with no link to the eventual goods receipt or invoice.
Advance payment voucher links to the PO. When the invoice arrives, the advance appears as a credit and only the balance requires payment.
Every GRN and invoice requires a separate accounting entry by the accounts team - a duplicate effort that delays accurate book-keeping.
The GRN and the matched invoice each post complete accounting entries automatically. No separate posting step. Books are current the moment goods arrive.
Frequently Asked Questions
Yes. Once a PO is approved, it can be printed in the configured template format or emailed directly from the system to the supplier's email address on record. The PO document includes all required fields: PO number, date, supplier name and address, item descriptions, quantities, prices, delivery address, payment terms, and the business's VAT number. The supplier can quote the PO number on their invoice, which makes the three-way matching process faster and reduces the risk of invoices being entered against the wrong purchase record.
A purchase return reverses the GRN for the returned items. The system reduces inventory by the returned quantity and credits the supplier's payable account (or generates a debit note if the invoice has already been settled and the supplier owes a refund). The return links to the original GRN and PO for a complete audit trail. If goods are returned before the supplier's invoice is settled, the return reduces the invoice amount payable automatically. If goods are returned after payment, the debit note creates a credit balance in the supplier's ledger that applies against the next purchase invoice.
Yes. Approval workflows are configurable by value threshold. A purchase requisition below Rs 50,000 might require only the department head's approval. Between Rs 50,000 and Rs 5 lakh, it might require the department head plus the finance manager. Above Rs 5 lakh, it might require the owner's sign-off. These thresholds and approver levels are configured in the workflow settings and apply automatically based on the requisition value. The approval chain is sequential - each approver receives a notification only after the prior level has approved, and the PO is only generated after the final approval level is cleared.
A Purchase Cycle That Runs Itself - With Full Audit Trail
MISAC's procurement module covers the complete purchase cycle: requisition with configurable approval workflows, PO generation with template-based printing and direct email to suppliers, GRN entry with automatic inventory update and accounting posting, three-way matching of PO-GRN-invoice, and payment release from the accounts payable queue. Every stage connects to the next. Every action posts the correct accounting entry automatically. The accountant's role shifts from data entry to review - confirming what the system has already recorded rather than creating records from source documents.
Custom fields on purchase forms handle Nepal-specific requirements: LC numbers for import purchases, project codes for construction procurement, department cost center allocation for multi-department businesses, and advance payment references for suppliers who require prepayment. These fields carry through from the PO to the GRN to the invoice, so the cost allocation information is consistent across the entire procurement record. Reports sliced by project, by supplier, or by cost center work from data that was entered once at the PO stage and never duplicated.
MISAC Intelligence Pvt. Ltd. has implemented purchase automation for trading companies, construction firms, and manufacturing businesses across Nepal. The purchase analytics layer - spend by supplier, price variance, open PO value, GRN completion rate - gives procurement managers and CFOs the forward-looking data to manage costs before they are incurred rather than after. That shift from reactive to proactive procurement control is what most Nepali businesses are missing and what automated PO workflow directly enables.
Ready to See MISAC in Action?
If your purchase orders still travel by WhatsApp and your accounts team finds billing discrepancies only after payment, talk to us about a procurement workflow that catches every discrepancy before it costs you money.