Procure to pay

Buying something and paying for it, end to end: registering the supplier, raising a requisition and a purchase order, receiving the goods, matching and recording the invoice, and paying it in a run.

Suppliers (/suppliers)

The supplier master is a governed record. Register a supplier (code, name, bank account) and activate it, which attests that due diligence is done.

A bank-account change forces re-review: the supplier moves to a bank-review state until a second person approves the new details. This closes off the classic payment-fraud vector, where an attacker quietly changes where a supplier is paid.

• Lifecycle: ONBOARDING → ACTIVE; a bank change → BANK_REVIEW → back to ACTIVE; block/unblock → BLOCKED.
• A blocked supplier cannot be given a purchase order.
• Supplier registration is optional upstream (you can still invoice an unregistered supplier), but paying one whose bank details are unverified is the risk it removes.

Permissions: supplier:read, supplier:manage, supplier:approve. Posts nothing (master data).

Requisitions (/requisitions)

The front of procurement, before the PO. Raise a requisition (requester, account, cost centre, lines, estimated total), submit it (budget-checked) and approve or reject it.

• Lifecycle: DRAFT → SUBMITTED → APPROVED (or rejected).
• Soft budget gate at submission: where a budget exists, a requisition beyond available = budget − actual − open commitment is refused. It raises no commitment itself. That is the PO's job.

Permissions: requisition:raise, requisition:approve, requisition:read. Posts nothing.

Purchasing (/purchasing)

Raise a purchase order, approve it (which commits you to the supplier), receive goods against it (a goods-received note, or GRN), and match the invoice.

• Lifecycle: DRAFT → APPROVED → PART_RECEIVED → RECEIVED → INVOICED. Cancel only before any receipt.
• The PO tracks cumulative received quantity per line across several receipts, and the GRN's value is derived from the PO cost, never re-keyed.

Three-way match

The supplier invoice is refused unless it agrees with what was ordered and what was received:

invoice net = received quantity × PO price (within a small rounding tolerance)

This catches a supplier billing a different price or quantity than was agreed and delivered. (Where a genuine price difference is expected, costing can absorb it as a purchase-price variance instead of refusing it.)

What it posts (GRNI)

Because goods often arrive before the invoice, Cortex uses goods-received-not-invoiced (GRNI) so inventory is debited when goods arrive, not when the paperwork catches up:

Event	Debit	Credit
Goods receipt	Inventory control	GRNI
Matched supplier invoice	GRNI, Recoverable input tax	Accounts payable

GRNI nets to zero once the invoice is matched, and inventory reconciles to stock the whole time. A direct (non-PO) invoice debits inventory or expense directly, with no GRNI.

Payables (/payables)

Record a supplier invoice (supplier, number, dates, net, tax, item type, a tax-recoverable toggle, optional cost centre and lines) and approve it. Approval is the point of no return: it emits the event, posts the journal, and the invoice can no longer be amended. Attach supporting documents (supplier invoice, delivery note, credit note).

• Statuses: DRAFT → APPROVED → PAID.
• The item type drives the posting: an inventory line debits inventory control, a service line debits operating expense.
• Tax recoverable on → claim input tax; off → the tax is absorbed into cost.
• Invoice lines let one invoice mix inventory and service lines, each posting to the right place.

What approval posts (recoverable-tax case):

Debit	Credit
Inventory control (inventory net), Operating expense (service net), Recoverable input tax	Accounts payable (gross)

Permissions: payables:read, payables:manage, payables:approve.

Payment runs (/payment-proposals)

Pay approved, unpaid invoices in a batch. Build a proposal (choose the paying bank account and a pay-by date; it gathers the invoices due by then into a draft), review, then execute.

• Lifecycle: DRAFT → EXECUTED (or cancelled). It executes at most once.
• Nothing pays until you execute: a proposal is a plan; execution is the act.

What execution posts, per paid invoice:

Debit	Credit
Accounts payable	Bank

Each invoice is then marked paid. Permissions: payables:pay to build, execute or cancel; payables:read to view.

Where it stops

Payment runs pay gross and post to the bank account; actual bank-file / rail submission is handled by the banking payments side. Early-payment discounts and partial payments are not yet modelled.