Procurement Management · requisition approval and budget control · Early access · opening gradually
Approve a requisition and encumber the budget in one fail-closed step — over budget is blocked, not overspent.
This is the approver’s side of a school’s requisition rail. Only a finance officer approves; approving a requisition encumbers its amount against the canonical general ledger in exact integer cents; and the run holds at “approved” because there is no pay or disburse step to move it further. An over-budget request does not squeak through and get reconciled later — it is refused at the ledger, before any money could be committed twice.
Procurement Management is being opened up gradually. The approve-and-encumber guard is built and tested behind a fail-closed finance-officer gate, but this product surface is not yet generally available. This page describes what the guard does and how it behaves; the honest next step is to ask about early access.
Role-gated approval
Only a finance officer approves. A teacher, parent, minor, or vendor rep is denied at the wall — before any application code runs.
Encumber on approval
Approving encumbers the budget in exact integer cents against the canonical general ledger. Over budget is blocked, not overspent.
No disburse step
The run holds at “approved”. “Paid” is unreachable — no pay, expend, or disburse endpoint exists in the flow.
What Procurement Management is
A school’s requisition rail has two halves. On the submission side, a finance officer files a requisition — the purchase request itself, in exact integer cents. Procurement Management is the other half: the side where that requisition is approved or rejected, and where approval encumbers the budget against the canonical general ledger. Approve and encumber are not two steps a person has to remember to keep in sync; they are one step the guard performs together, or not at all.
It is deliberately narrow. It re-implements no procurement policy, it does not build a second ledger beside the school’s, and it does not decide what a school is allowed to buy. It binds the canonical general ledger the school already keeps, asks that ledger whether the money is there, and — when it is — sets it aside. The approval response returns the new encumbered balance for the caller to persist to the system of record; the guard computes and refuses, the ledger of record remembers.
Honestly, where the build is: the approve-and-encumber guard underneath this page is written and tested behind a fail-closed finance-officer gate, but this product surface is early access and is being opened up gradually. The honest next step is to ask about early access.
The finance-officer wall, fail-closed
Approval is not a permission a busy office hands around. Only a finance officer can approve or reject a requisition. A teacher, a parent, a student, or a vendor representative is denied at the wall — and denied for the right reason: the check fails closed. A request that arrives without a resolvable finance role is refused, not waved through on the assumption that someone would have caught it.
The wall is not only in the application code; it is in the database. A RESTRICTIVE finance-role wall means a non-finance session reads zero rows of requisition, account, fund, and budget data at the database engine — before a single line of application logic runs. So even a bug in a route, or a request that skips a check it should have hit, does not turn into a leaked requisition: there is nothing there to read for a session that is not a finance session.
This is what “fail-closed” means on this page, said plainly: the safe default is no. The system does not approve, does not encumber, and does not disclose unless the caller is proven to be a finance officer and the budget is proven to be there.
Encumbrance, worked out plainly
Schools keep money in funds against budget authority — the amount an account is allowed to spend. An encumbrance is a commitment of that authority: money set aside for a request that has been approved but not yet paid, so it cannot be quietly committed to something else. The plain-language identity the guard defends is this: budget authority, minus what is already encumbered, minus what has already been expended, equals the available balance. A requisition can only be approved while it fits inside that available balance.
Every amount is an exact integer number of cents. There is no floating-point dollar figure that rounds a fraction of a cent into or out of existence over a year of approvals; a requisition for four hundred and ninety-nine cents is four hundred and ninety-nine cents, checked and encumbered as an integer. Rounding drift is not a small bug in a ledger — it is the bug — so the guard never introduces it.
When a finance officer approves, the guard checks the requisition amount against the available balance on its account and fund. If it fits, the amount is encumbered: the available balance goes down by exactly that many cents, and the approval response returns the new encumbered total for the caller to persist. If it does not fit — if approving it would push the account past its authority — approval is refused at the ledger. The request is blocked; it is not approved-then-flagged, and it is not overspent and reconciled next month. Over budget cannot happen, because the step that would have committed the money simply does not complete.
The states a requisition can be in
A requisition moves from submitted to approved or rejected, and reading it back gives a plain-language status a person can act on. There is one state the flow is built not to reach.
Submitted
The requisition has been filed on the submission side and is waiting on a finance officer. No budget is set aside yet.
Approved (encumbered)
A finance officer approved it and the guard encumbered its amount against the canonical ledger. This is where an approved run HOLDS. It does not advance on its own.
Rejected
A finance officer rejected it. Nothing is encumbered; the available balance is untouched. The record keeps the rejection as its plain-language status.
Paid
Unreachable. There is no pay, expend, or disburse endpoint in the flow, so nothing can move a run from approved to paid. The page does not pretend otherwise.
Money is honest-off by construction
Money being honest-off here is not a switch someone remembered to leave off. Approval only encumbers — it sets budget aside and stops. There is no pay, no expend, and no disburse endpoint anywhere in the flow, and no charge rail is touched, so there is nothing to disable and nothing that could be flipped on by accident. An approved run holds at “approved”; disbursement is never reached because it is not built.
So this page claims exactly what the guard does and no more: it approves, it encumbers a budget set-aside, and it reads back a status. It does not move real money, it does not transmit a live purchase order to a vendor, and it does not cut a check. Encumbrance is a budget guard, not a payment. When a real disbursement rail is ever built, it will be its own surface, gated on its own terms, and it will say so.
Anonymous finance data, walled at the row
The records this guard touches are about requisitions and budgets, not about children. Each row carries opaque finance references — a requisition id, an account id, a fund id, a budget id — and never a student id and never PII. There is no name, no roster link, and no minor’s data anywhere in the requisition rail; the finance office’s job here does not need one, so it never carries one.
Access is walled at the database, not just in the app. The RESTRICTIVE finance-role wall means a session that is not a finance session reads zero rows at the database engine, before any application code runs — the same wall that gates approval also gates disclosure.
To be plain about it: this is not a “we hold no data” claim. A requisition is data. The honest claim is narrower and truer — it is finance data made of opaque references, carrying no student identity, kept behind a row-level wall, and read by finance sessions only.
Common questions
How is this different from Procurement Center?
They are the two halves of one requisition rail. Procurement Center is the SUBMISSION side — a finance officer files a requisition that is the purchase request. Procurement Management is the APPROVAL and budget-control side — where that requisition is approved or rejected and where approval encumbers the budget. Same rail, two surfaces, kept separate on purpose.
What does it mean to encumber a budget?
To set money aside. When a requisition is approved, its amount is committed against the account’s budget authority so it cannot be spent on anything else. Available balance is budget authority minus what is already encumbered minus what has already been expended. A requisition can only be approved while it fits inside that available balance — every amount in exact integer cents.
What happens if a requisition is over budget?
Approval is refused at the ledger. If approving a requisition would push its account past its authority, the guard blocks it — it is not approved and then flagged, and it is not overspent and reconciled later. The step that would have committed the money does not complete, so over budget cannot happen.
Can this pay a vendor or cut a check?
No. Approval only encumbers. There is no pay, expend, or disburse endpoint anywhere in the flow, and no charge rail is touched, so “paid” is a state the flow cannot reach. An approved run holds at “approved”. Money is honest-off by construction, not by a toggle.
Who is allowed to approve?
Only a finance officer. A teacher, parent, student, or vendor representative is denied at the wall, and the check fails closed — a request without a resolvable finance role is refused, not waved through. A RESTRICTIVE finance-role wall means a non-finance session reads zero rows at the database engine, before any application code runs.
Is this our accounting system of record?
No, and it does not pretend to be. It binds the canonical general ledger the school already keeps and builds no parallel ledger and no parallel procurement policy. It is a guard: it checks and encumbers, and the approval response returns the new encumbered balance for your system of record to persist. It complements the ledger; it does not replace or certify it.
What data does it hold about students?
None. The records carry only opaque finance references — requisition, account, fund, and budget ids — never a student id and never PII. This is not a “no data” claim: a requisition is data. The honest version is that it is anonymous finance data behind a row-level wall, read by finance sessions only.
How much does it cost, and can we use it now?
There is no pricing on this page, and not generally, yet. The guard is built and tested behind a fail-closed finance-officer gate, but this product surface is early access and is being opened up gradually. The honest next step is to ask about early access and talk through what your finance office needs.
Related surfaces
Procurement Management is the approval and budget-control half of the requisition rail. These adjacent destinations cover the submission half and the platform underneath.
procurement.center
The submission side of the same requisition rail — where a finance officer files the requisition that is the purchase request. This page is the approval and budget-control half; the two are kept as separate surfaces.
homeroom.software
The school platform this back-office rail runs on. The canonical general ledger that approval encumbers against lives there, alongside the rest of the platform.
What this page is and is not claiming
Procurement Management — a fail-closed approve-and-encumber guard for a school’s requisition rail — is built and tested behind a fail-closed finance-officer gate, but this product surface is early access and not yet generally available. This page describes the guard’s design and behaviour; it does not present early access as a finished, open product. There are no invented stats, testimonials, or adoption counts here. Only a finance officer approves, and a non-finance session reads zero rows at the database engine. Approval encumbers only: an over-budget request is blocked at the ledger, not overspent, and every amount is exact integer cents. Money is honest-off by construction — there is no pay, expend, or disburse endpoint, so “paid” is unreachable and no charge rail is touched. It binds the canonical general ledger and builds no parallel ledger. Privacy is stated honestly: the records carry opaque finance references, never a student id and never PII — not a claim that no data exists. No competitor or school-ERP brand names appear on this page. The honest next step is to ask about early access.