Procurement
This page is generated from the in-app guide content — edit
featureToggleGuidesand runpnpm gen:feature-toggle-docs.
Block payment on 3-way exception
Refuse bill payment while a quantity or price discrepancy is open on the PO
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.block_pay_on_match_exception | Off | /procurement/settings | — |
How it works
Every payment or netting settlement against a vendor bill checks that bill’s own 3-way match result; an open (not approved) quantity or price discrepancy on that bill refuses the payment.
Conditions for it to take effect
Needs discrepancies to be recorded — in practice Three-way matching must be on.
When ON
Payments (Payments page, bill payment, AP payment runs, payment approval release, bank reconciliation, AI assistant) and contact statement netting for a bill with an open discrepancy are refused until the discrepancy is approved (resolved) or the bill is voided.
When OFF
Discrepancies are only shown; payments go through (default).
Screens, documents and reports affected
Payments, bill payment, AP payment runs, payment approval, bank reconciliation, 3-way match resolution.
Caveats
Only discrepancies recorded on the bill itself count — another bill of the same PO, or the manual “Run 3-way match” result, does not block this bill. Turning it off releases nothing — the discrepancy stays open, it just no longer blocks.
Landed Costs
Allocate additional costs (freight, customs, insurance) of a goods receipt onto the cost of received goods. Charge lines on POs and bills are not controlled by this toggle.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.landed_costs | Off | /procurement/settings | — |
How it works
Allows landed cost allocations on confirmed goods receipts: extra costs (freight, duty, insurance…) are spread over the receipt lines by value, weight or quantity and capitalised. Units still in stock get the cost (FIFO layer / average cost; standard cost is not changed), units already issued are expensed to cost of goods sold, units issued to an open production order go to its WIP. Journal: Dr inventory, Cr landed-cost clearing (mapping purchase.landed_cost_clearing), import duty to its payable account.
When ON
The landed cost button and forms appear on the PO / goods receipt; draft allocations entered before receipt are applied automatically when the receipt is confirmed.
When OFF
New allocations cannot be created, allocated or edited, and draft allocations are not applied on receipt confirmation; the landed cost controls are hidden and a notice is shown. Off by default for existing tenants; new tenants start with it on.
Screens, documents and reports affected
Purchase order detail (landed cost dialog), goods receipt confirmation, inventory valuation, production order costing, vendor bills (lines on the clearing account are exempt from 3-way match).
Caveats
Turning it off still lets you delete draft allocations, and allocations already applied keep their consequences (deferred posting, reversal when the receipt is voided). Additional charge lines on POs, quotes, bills, vendor returns and invoices (before-tax/tax/after-tax) are a separate feature not controlled by this toggle. Map the clearing account before turning it on, otherwise posting falls back to 338/331. Pay the freight/customs vendor with a bill line on the clearing account to clear it.
Purchase categories & category approval
Category access rules (who can request, view, approve each restricted category) and approval routing to the category’s approver. Documents are stamped with a category from item master data either way. Off = no category access rules, approval follows the standard workflow.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.categories | Off | /procurement/settings | — |
How it works
Turns on category ACL and category approval routing. Every requisition, RFQ, PO, goods receipt, vendor bill and vendor return is stamped with a purchase category from the item’s master data (or the GENERAL category) whether this is on or off.
When ON
Categories marked restricted only show to people granted access (request ≤ view ≤ approve ≤ manage) on requisitions, RFQs, POs, goods receipts, vendor contracts, vendor returns, quotes and service confirmations. Requisition approval can route to the category’s workflow, owner department or approver. The category picker appears on requisition and PO forms and lists.
When OFF
No category access filtering and no category-based routing; category pickers and the category settings page are hidden, category settings cannot be edited. A requisition or PO whose lines come from different categories is accepted and gets the GENERAL category.
Screens, documents and reports affected
Requisition and PO forms and lists, inventory item form, Procurement → Settings → Categories, spend by category report, approval workflows with a “category approver” step.
Caveats
Vendor bills are stamped but never filtered by category. While on, a requisition or PO whose lines belong to two different categories is refused (one document, one category). Turning it off keeps categories, grants and restrictions — they apply again when you turn it back on. A workflow step “category approver” falls back to its fallback role while off (no fallback ⇒ no approver found). Admins always see every category. Sales and service groups have their own toggles.
Purchase price variance treatment
Standard cost: on goods receipt, book the standard-vs-actual difference to the price variance account (expense) or keep inventory at actual cost (capitalise). FIFO / average: the difference between the vendor bill and the receipt price goes to the variance account (expense) or into inventory value for units still in stock and to the consumer of units already issued (capitalise).
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.ppv_treatment | expense | /settings/erp-configuration | — |
How it works
Two differences, one choice. Standard cost: on goods receipt, “Expense” (default) books inventory at standard cost and the standard-vs-actual difference to the purchase price variance account (mapping purchase.ppv); “Capitalise” books inventory at actual cost. FIFO / weighted average: when a vendor bill line linked to a receipt line is priced differently from the receipt, the bill posts the difference to the variance account; with “Capitalise” a separate entry then moves it out of the variance account: the share of units still in stock into inventory value (FIFO receipt layer or average cost), the share of units already issued to cost of goods sold, to WIP of an open work order, or to manufacturing variance for a closed work order (same split as landed costs).
When ON
“Capitalise”: standard cost — receipts post inventory at actual cost; FIFO/average — bill-vs-receipt price differences end up in inventory value and in the cost of what was already issued, not in the variance account.
When OFF
“Expense” (default): standard-vs-actual and bill-vs-receipt differences stay in the variance account.
Screens, documents and reports affected
Goods receipt entries (standard cost); vendor bill entries plus a landed-cost type entry “price variance”, item average cost / FIFO layers (FIFO, average).
Caveats
Only bill lines linked to a receipt line, whose receipt already has its journal entry, are capitalised; other differences stay in the variance account. Foreign-currency bills use the bill’s exchange rate (the rate difference against the PO goes to realised FX). Voiding the bill reverses the capitalisation measured on stock at void time: units issued since the bill reverse out of cost of goods sold. Items capitalised as fixed assets get the difference on the asset cost account; the asset card is not updated. Changing the setting only affects documents posted afterwards.
Require GRN Before Billing
Vendor bills can only be created after a goods receipt note is confirmed
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.require_grn_before_bill | Off | /procurement/settings | — |
How it works
When a vendor bill is created against a purchase order, a confirmed goods receipt must exist for that PO, and the quantity you can bill per line is capped at what was received (instead of what was ordered).
When ON
Bills from a PO with nothing received are refused; “Create bill from PO” only offers received quantities.
When OFF
Bills can be created from a PO up to the ordered quantity before receiving (default).
Screens, documents and reports affected
Bill creation (manual with a PO, from PO, AI assistant), PO “Create bill” action.
Caveats
Bills from service confirmations, recurring, CSV-imported, opening, intercompany and subcontracting bills are not checked. Bills already created are not re-checked when you turn it on. Three-way matching also caps billed quantity at received, so with that on this toggle mainly adds the “a receipt must exist” check.
Require Purchase Requisition before PO
New purchase orders, on every creation path, must come from an approved requisition (linked lines, header requisition, or an RFQ converted from one). Checked at creation; subcontracting POs, blanket releases and migration import are exempt.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.require_pr | Off | /procurement/settings | — |
How it works
Checked when a purchase order is created, on every creation path: the PO must come from an APPROVED purchase requisition — lines linked to approved requisition lines, an approved requisition on the header, or an RFQ that was converted from an approved requisition.
When ON
Refused without a requisition: creating a PO by hand, cloning a PO, creating POs from inventory reorder suggestions, AI assistant/agent actions, field service automatic POs, and awarding a quote on an RFQ that did not come from a requisition. Converting a requisition to a PO always satisfies it. Back-to-back POs from a sales order and new blanket POs cannot be created while this is on.
When OFF
POs can be created with or without a requisition (default for existing and new tenants).
Screens, documents and reports affected
New purchase order form, requisition → PO conversion, sales order → PO, blanket PO, AI purchase order and reorder actions, field service automatic POs.
Caveats
Only creation is checked: drafts created before you turned this on can still be submitted, approved and received. Exempt by design: subcontracting POs (every line tied to a work order operation), releases from an existing blanket PO, and migration import of open documents. When a field service requisition cannot create its PO because of this toggle, the reason is written on the requisition — raise a requisition by hand.
Example
Turn on together with Require RFQ to force requisition → RFQ → award quote; the award step then creates the PO and passes both checks.
Require RFQ before Purchase Order
New purchase orders, on every creation path, must reference an RFQ that has been sent and has at least one vendor quote; requisitions cannot be converted straight to a PO.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.require_rfq | Off | /procurement/settings | — |
How it works
Checked when a purchase order is created, on every creation path: the PO must reference an RFQ of the company that has been sent (not draft or cancelled) and has at least one vendor quote.
When ON
Refused without such an RFQ: creating a PO by hand, cloning a PO, POs from inventory reorder suggestions, AI assistant/agent actions and field service automatic POs. Converting a requisition straight to a PO is refused (the button is hidden) — go through an RFQ. Back-to-back POs from a sales order and new blanket POs cannot be created.
When OFF
POs can be created without an RFQ (default for existing and new tenants).
Screens, documents and reports affected
New purchase order form (the “from requisition” source is hidden), requisition detail actions, RFQ award, sales order → PO, blanket PO, AI purchase order and reorder actions, field service automatic POs.
Caveats
Only creation is checked: existing drafts are not re-checked. Awarding a quote on an RFQ always satisfies it. Exempt by design: subcontracting POs, releases from an existing blanket PO, and migration import of open documents.
Three-way match tolerance (%)
Percentage difference between PO, receipt and bill that is accepted without review.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.three_way_tolerance_pct | 2 | /settings/erp-configuration | — |
How it works
Maximum price difference per bill line, as a percentage of the PO unit price: |bill unit price − PO unit price| ÷ PO unit price × 100. Default 2.
Conditions for it to take effect
Only takes effect when Three-way matching is on.
When ON
A bill line whose price difference exceeds this value fails this test; whether that makes a price discrepancy depends on the Tolerance rule.
When OFF
0 means any price difference counts against the percentage test. Empty uses the default 2.
Screens, documents and reports affected
Price discrepancies recorded when a bill is marked received; through them, Block payment on 3-way exception.
Caveats
Combined with the amount tolerance by the Tolerance rule. Applies to price only — quantity has no tolerance. The manual “Run 3-way match” uses its own fixed 0.5%. A negative value is treated as 0.
Three-way match tolerance (amount)
Absolute price difference per bill line accepted without an exception, in company currency (converted with the bill’s exchange rate).
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.three_way_tolerance_amount | 50000 | /settings/erp-configuration | — |
How it works
Maximum price difference per bill line as an amount, in the company’s base currency: |bill unit price − PO unit price| × billed quantity, converted with the bill’s exchange rate. Default 50,000.
Conditions for it to take effect
Only takes effect when Three-way matching is on.
When ON
A bill line whose price difference exceeds this value fails this test; whether that makes a price discrepancy depends on the Tolerance rule.
When OFF
0 means any price difference counts against the amount test. Empty uses the default 50,000.
Screens, documents and reports affected
Price discrepancies recorded when a bill is marked received; through them, Block payment on 3-way exception.
Caveats
Combined with the percentage tolerance by the Tolerance rule. A negative value is treated as 0.
Three-Way Matching
Vendor bill goods lines must link to PO lines and cannot bill more than received; when a bill is marked received, price/quantity differences against the PO are recorded as exceptions. Blocking payment is a separate toggle.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.three_way_match | Off | /procurement/settings | — |
How it works
Two effects. (1) When a vendor bill is created, every goods line must be linked to a PO line, and the billed quantity per line cannot exceed received − already billed. (2) When the bill is marked received, each PO-linked line is compared with the PO price and received quantity, and the result (matched / price discrepancy / quantity discrepancy) is recorded for that PO and bill.
When ON
Bills with goods lines not linked to a PO, or billing more than was received, are refused. Discrepancies are recorded and shown on the PO 3-way match tab and the matching screen; the bill itself still moves on.
When OFF
Bills can be created without PO links and no match result is recorded when a bill is marked received. Off by default for existing tenants; new tenants start with it on.
Screens, documents and reports affected
Bill creation (manual, AI assistant, asset billing), marking a bill received, PO 3-way match tab, Procurement → Matching, the 3-way exception agent (skipped on automatic runs while off).
Caveats
Recording a discrepancy does not block payment — turn on “Block payment on 3-way exception” for that. Price tolerance comes from the three tolerance settings; quantity has no tolerance (any billed quantity above received is a discrepancy, service lines excepted). Recurring bills, bills from service confirmations, CSV-imported and opening bills, intercompany and subcontracting bills are not checked. Note/section lines and lines on the landed-cost clearing account are exempt. The manual “Run 3-way match” action and the PO match status set on receipt/bill events use their own fixed tolerances and are informational only. Turning it off does not clear recorded discrepancies.
Tolerance rule
Whether a bill line is flagged only when it exceeds both the percentage and the amount tolerance, or when it exceeds either one.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
procurement.three_way_tolerance_condition | and | /settings/erp-configuration | — |
How it works
Decides how the percentage and amount tolerances combine. “Flag only when both are exceeded” (default): a line is a price discrepancy only if it is over the percentage AND over the amount — staying within either one is enough. “Flag when either is exceeded”: over the percentage OR over the amount is a discrepancy.
Conditions for it to take effect
Only takes effect when Three-way matching is on.
When ON
Stricter choice: “either”. Looser choice: “both” (default) — the amount works as a floor so tiny lines with a large percentage difference are not flagged.
When OFF
There is no off; the default is “both”.
Screens, documents and reports affected
Price discrepancies recorded when a bill is marked received; through them, Block payment on 3-way exception.
Caveats
Quantity differences are never subject to tolerance.