Purchase orders, receiving and supplier payments

Purchase orders and receiving, in brief

Buying stock in Skyline Nexus ERP can run through three separate documents: a Purchase Requisition to ask for stock, a Purchase Order to commit a supplier to a price and date, and a Purchase to actually receive the goods and take them into inventory. It matters because only the last of these moves stock and money; a business that raises orders without knowing which document is which ends up paying for goods before they arrive, or receiving stock that was never formally ordered.

This guide covers the requisition-to-order-to-receiving chain, supplier payments and purchase returns, and what each step posts. It does not repeat how to record a purchase, which already explains what Received, Pending and Ordered mean on a single purchase and how input tax is captured line by line; here the focus is the documents around that purchase and the payment that follows it.

Three documents, three purposes

Purchase Requisition, Purchase Order and Purchase (the receiving document) sit together under the Purchases menu, but only the ones a business has switched on and been given permission for appear. A requisition is a request for stock, raised by product Category and Brand rather than a specific supplier: Business Location, a Reference No., and a Required by date are the only real fields, because at this stage nobody has decided who to buy from yet.

A Purchase Order commits to a named Supplier at an agreed price: it carries an Order Date, Delivery Date, Currency Exchange Rate, Pay Term, and can pull one or more open Purchase Requisitions into itself so the paperwork trail runs from request to order. A Purchase Order also carries its own Shipping Details, Shipping Address, Shipping Charges and Shipping Status, separate from the order's own status, so a shipment can be tracked as ordered, packed, shipped, delivered or cancelled independently of whether the order itself is still open.

• Purchase Requisition: Business Location, Category, Brand, Reference No., Required by date
• Purchase Order: Supplier, Order Date, Delivery Date, Exchange Rate, Pay Term, linked Requisitions, Shipping Status
• Purchase (receiving): Supplier, Purchase Date, Purchase Status, linked Purchase Order, tax and payment detail

Before you start

A little configuration decides whether staff even see the requisition and order screens, or default straight to a plain purchase. Getting this right before the first order matters more than it looks, because a business that never enables requisitions and orders has no record of what it has committed to buy until the goods, and the bill, actually arrive.

• Purchase requisitions and purchase orders switched on in settings, or the Purchases menu shows only the plain Purchase screen
• A named Supplier contact created for each vendor, with its Pay Term set (see our guide on customers, suppliers and contacts)
• Products and their purchase price already set up, so requisition and order lines can be built
• Auto-post Purchase Transactions switched on in Fiscal Authority, so a received purchase actually posts a journal
• A current fiscal period open for the purchase date

Raising a requisition and an order

Start at Purchases, Purchase Requisition, and list what is needed by category or brand with a Required by date, so whoever buys has a deadline rather than an open-ended request. From there, Purchases, Purchase Order lets that requisition be turned into a firm order: choosing the supplier, confirming the price and delivery date, and pulling the requisition lines in rather than retyping them. Saving a new order sets its status to Ordered, and if it came from a requisition, that requisition's own status updates to show it has been actioned.

A Purchase Order is a commitment, not a receipt: nothing has moved into stock and, used as intended, nothing has been paid yet. The order exists so a business can track what it is owed by suppliers before the goods turn up, and so a delivery can be checked against what was actually ordered rather than against memory. Keeping the requisition and the order as separate steps also gives a small business a natural approval point: whoever raises the requisition is not necessarily the person who is trusted to commit the business's money to a named supplier, and splitting the two documents makes that separation visible on the record rather than only in who happens to have access to the screen.

Receiving: turning an order into stock

Goods arrive through Purchases, Add Purchase, not through the Purchase Order screen itself: the Add Purchase form has its own Purchase Order field to link back to the order being received against. Purchase Status defaults to Received, alongside Ordered, Pending and Partial, and it is this field, not the Purchase Order's own status, that decides whether the goods are treated as in stock. A partial delivery is recorded with status Partial and the quantities that actually arrived, leaving the rest of the order open for a later delivery.

Only once a purchase carries status Received does it behave as a finished transaction: stock increases at the cost the purchase lines record, and, with Auto-post Purchase Transactions on, a journal posts crediting Accounts Payable for the supplier's invoice and debiting inventory and recoverable tax. That distinction is also why the Purchase Status field carries a tooltip on the form: it is easy to assume Ordered and Received are just labels for the same document at different points in time, when in the ledger they are the difference between a commitment that has not yet moved money or stock and a transaction that has.

Worked example: requisition to receiving in Canadian dollars

A Canadian hardware retailer requisitions 50 units of a fastener line for its Ottawa branch, required within two weeks. The buyer converts it into a Purchase Order with supplier Northline Supplies, CAD 5,000 before tax, 5 percent GST adding CAD 250, for a CAD 5,250 order, status Ordered. Ten days later the full 50 units arrive with Northline's invoice: the buyer opens Add Purchase, links the Purchase Order, confirms the quantities and sets Purchase Status to Received.

Because Auto-post Purchase Transactions is on, saving the received purchase posts a balanced journal the moment it is saved, debiting inventory for the goods received and GST for the recoverable tax, and crediting the amount owed to Northline Supplies in full. Had Auto-post Purchase Transactions been off, the purchase and the stock movement would still save, but no journal would exist until someone turned the toggle on and re-triggered posting, leaving the trial balance quietly out of step with the stock report in the meantime.

• Dr Inventory 5,000.00
• Dr GST Input 250.00
• Cr Accounts Payable 5,250.00

Paying the supplier

A supplier is paid from the same Pay action used for any contact due: from the Suppliers list, or from the purchase itself, which opens the standard payment screen against that contact's outstanding balance. That action, and the ability to edit the purchase further, only appears once the purchase carries status Received with an amount still due, which is the point of keeping receiving and payment as separate, sequential steps.

Continuing the Ottawa example, the retailer pays Northline Supplies CAD 3,000 against the CAD 5,250 owed, leaving CAD 2,250 outstanding and the purchase's payment status showing partial rather than paid. The payment itself debits Accounts Payable and credits the bank account it was paid from, for the CAD 3,000 actually paid, leaving the remaining balance on Northline's supplier ledger until the next payment clears it.

• Dr Accounts Payable 3,000.00
• Cr Bank 3,000.00
• Remaining due to Northline Supplies: CAD 2,250.00

Purchase returns

Faulty or wrong stock goes back through Purchases, Purchase Return, which records a debit note against the original purchase rather than editing it directly, keeping the original receiving document intact for audit purposes. Continuing the example, five of the fifty units are returned as defective, CAD 500 before tax plus CAD 25 GST, a CAD 525 debit note against Northline Supplies.

The return reverses the original entry for the returned quantity: inventory falls by the cost of the units sent back, the recoverable GST on those units reverses with it, and the amount owed to the supplier falls by the full debit note value, whether that reduces what is still due or creates a credit to be applied against the next order.

• Dr Accounts Payable 525.00
• Cr Inventory 500.00
• Cr GST Input 25.00

Common mistakes and how to fix them

Most purchasing problems come from treating the three documents as interchangeable, rather than as a sequence with a specific job each. A supplier statement that does not match the purchase ledger is usually traceable to one of these, rather than to a genuine dispute with the supplier.

• Raising every order as a plain Purchase with status Ordered because the Add Purchase Order screen is hidden: the Add Purchase form's payment section is not gated by Purchase Status, so a payment can be entered against goods that have not arrived yet, moving cash and the supplier balance ahead of the delivery
• Marking a purchase Received before checking the delivery against the order, which pulls stock and cost into the ledger for goods that have not actually been counted in
• Recording a partial delivery as fully Received, overstating stock and understating what the supplier still owes to deliver
• Skipping the Purchase Order stage entirely for large or long-lead-time buys, losing the ability to see what has been committed but not yet delivered
• Editing a received purchase's quantities or price directly instead of using a Purchase Return, which breaks the audit trail back to the original document
• Paying a supplier from the wrong bank or cash Payment Source, so the account that is meant to fall does not, and the one that should not move does

Related reports

The requisition-order-receiving chain and its payments are checkable from the same reports used across the rest of purchasing, so a discrepancy can be traced to the specific document that caused it rather than argued over from the supplier's statement alone.

• Purchases, List Purchase, filtered by status, to see what is Ordered, Pending, Partial or Received
• Purchases, Purchase Order list, filtered by status, for everything committed but not yet fully received
• Fiscal Authority, Reports, AP Aging Report, for what is owed to each supplier and for how long
• Contacts, Supplier Ledger and Accounts Payable Report, for a single supplier's full purchase and payment history
• Fiscal Authority, Reports, Data Verification, to compare purchase documents against what actually posted to the ledger