Procurement & Purchasing

Softbooq Go

Money leaves the business here. Everything is built around that.

A request routed to someone with the authority to approve it. An order matched against what actually arrived. A payment that cannot be released twice, to an account nobody quietly changed, in a bank format that suits the country you are paying into.

The Procurement workspace in Softbooq

An unretouched screenshot from a live workspace.

01

Asking, quoting, ordering

The front of the process, where getting the paperwork right costs nothing and getting it wrong costs the rest of the chain.

Requisitions routed by amount and ownership

Internal requests go to an approver chosen by value, cost centre or dimension ownership, in sequence where your policy needs it - and the approval is recorded against a person.

Authorisation checked server-side, not by the button

The approve action verifies that the person clicking is an approver for that stage and is not the raiser. Requisitions use the same resolver vendor bills already do, rather than a second set of rules that can drift from it.

Quotes from several suppliers, compared side by side

Send one request to several suppliers, see the responses together, and convert the winner into an order without re-entering the lines.

Orders, and what is still outstanding on them

Issue formal purchase orders and see at a glance what has been received, what is part-delivered and what has not moved - rather than inferring it from whether anyone has chased.

Templates and recurring orders

The order you place every month raised from a template on a schedule, so routine buying stops consuming attention that should go to exceptions.

Budget checked before the commitment, not after

A purchase that would breach its budget is held at approval with the reason attached to the document, so the conversation happens before the order goes out.

02

What arrived, and what you were billed for

The three documents that should agree, and the discipline of noticing when they do not.

Goods receipt against the order

Receive fully or in part, at the location it actually arrived at, incrementing stock as it lands rather than when someone gets round to it.

Only the exceptions reach a person

A bill that matches its order and receipt clears itself. One that does not opens with the variance stated - which line, ordered against received against billed - instead of a generic mismatch flag.

Received-not-invoiced tracked as a liability

Goods you have taken delivery of but not yet been billed for sit in their own account, so the balance sheet reflects what you owe rather than only what has been invoiced.

Supplier credit notes against the original

A credit from a supplier is applied to the bill it relates to, so what remains payable is what remains payable.

03

Paying, without paying twice or paying the wrong account

The part with the most money at stake and the most ways to lose it quietly.

Batch what is due, export the right bank file

Group payables into a run, produce the file your bank expects or pay through a connected provider, and send each supplier their remittance advice on settlement.

Payment instruments by scheme, not one European shape

A party holds instruments that declare their scheme, each with its own identifier fields, validation and target bank format. Supporting another country is a registry entry, not a schema migration.

Changing bank details voids the verified status

A supplier account number that changes re-triggers verification rather than being quietly accepted - because a changed bank account is precisely how invoice fraud is executed.

Release gates before money moves

A bill held by an unresolved match exception or a budget breach does not enter a run. The hold is written onto the document with its reason, so the block is explainable rather than mysterious.

Early-payment discounts, in money

Pay by Thursday and save a stated amount, shown on the run itself - plus a look back at what was captured and what was left on the table. Terms nobody can see are terms nobody takes.

04

Letting suppliers do their own admin

Every status question a supplier asks you is a question they could have answered themselves.

A portal per supplier

Their orders, the quotes you asked for, and their payment position - so the call asking when an invoice will be paid mostly stops happening.

They acknowledge orders and post deliveries

A supplier confirms a purchase order and reports a delivery update themselves, and it writes back to the order rather than arriving as an email somebody has to transcribe.

The details that took the longest

Small decisions you only make after getting them wrong.

Every one of these is a specific behaviour, chosen for a specific reason. They are the difference between software that demos well and software that survives a year of month-ends.

The approve button used to be the entire control

Requisition approval lived in the screen: it advanced the chain if one existed and otherwise stamped Approved. Nothing checked the clicker was an approver for that stage, and nothing stopped the raiser approving their own request - while the tab offers bulk approve, so one person could select every open requisition and clear the lot. Authorisation is now resolved server-side, by the same resolver vendor bills use.

A US routing number was becoming an invalid IBAN, silently

Bank details were one flat shape that assumed a European account, and the SEPA exporter wrote the account number straight into an IBAN element. Nothing complained. Instruments now declare their scheme, and the scheme owns its identifier fields, its validation and which bank file it belongs in - so a new country is a registry entry rather than another field and another assumption.

Being billed for less than you received is not an exception

Matching flags over-billing, over-charging and lines that were never ordered. Partial delivery and under-billing pass, because they are legitimate. A matcher that treats every difference as a problem trains people to click through the ones that matter.

Nothing is an island

What reaches Procurement without anyone typing it again.

Every one of these is a real data path, not a promise of "full integration".

Inventory

Goods receipt increases stock at the delivery location

Finance

Vendor bills and payments post to the ledger

Manufacturing

Component shortages raise purchase requests

Projects

Purchases can be attributed to a project or cost centre

Assets

A capital purchase becomes an asset and clears goods-received

Public Portal

Suppliers acknowledge orders and post deliveries

Before you ask

Questions people ask about Procurement.

Does Softbooq do three-way matching?
Yes. Vendor bills are checked against the purchase order and the goods receipt before posting, and only genuine over-billing is raised for review.
Can approvals depend on the amount?
Yes, and on cost centre and dimension ownership, with stages in sequence. Authorisation is checked server-side, so the button is not the control.
Can I pay suppliers outside Europe?
Yes. Payment instruments declare their scheme, each with its own identifier fields and validation, so a non-IBAN account is not forced into an IBAN field.
What stops a supplier being paid twice?
Payments run in batches with release gates: a bill held by a match exception or a budget breach cannot enter a run, and the hold is written on the document with its reason.
What happens if a supplier changes their bank details?
The verified status is voided and verification is re-triggered, because a changed account is how invoice fraud works.
Can suppliers see their own orders?
Yes, through a supplier portal covering orders, requests for quote and payment position, where they can acknowledge orders and post delivery updates that write back.

See Procurement with your own numbers in it.

Start a free 30-day trial. No card required. Every module unlocked from day one.

© 2026 Softbooq by Everbright & Co. - Germany, European Union