Procurement Center · the school purchasing hub · Early access · opening gradually
A purchasing hub where a requisition is the record — submit the buy-it request, and the budget is checked before it moves.
This is the front door of a school’s requisition rail. A finance officer files a requisition — the purchase request itself, in exact integer cents, drawing on a named account and fund — and before it moves, the hub checks it against the available balance on the canonical general ledger, so the officer knows up front whether it fits. That check is read-only: this front door previews the fit, it does not commit the money. The commitment happens later, on the approval side, and this page hands the requisition off there.
Procurement Center is being opened up gradually. The submit-and-budget-check flow 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 front door does and how it behaves; the honest next step is to ask about early access.
The requisition is the record
A finance officer files a requisition that IS the purchase request — every amount in exact integer cents, drawing on a named account and fund. The record is the source of truth, not a spreadsheet beside it.
Budget checked before it moves
Before a requisition moves, the hub reads the canonical general ledger and checks it against the available balance. Over budget is surfaced up front, not discovered after approval.
Money honest-off by construction
The front door records the request and previews the fit. It moves no real money and there is no pay, expend, or disburse step — a filed run holds at “submitted”.
What Procurement Center is
A school’s requisition rail has two halves. Procurement Center is the submission half — the purchasing hub where a requisition is created. A finance officer files a requisition: the purchase request itself, in exact integer cents, with its line items, an optional vendor reference, and the account and fund it draws on. That requisition is not a note that a purchase order will be typed up somewhere else later — it is the record the rest of the rail acts on.
Before a requisition moves, the hub does one honest thing with the money: it reads the canonical general ledger and checks the requisition amount against the available balance on its account and fund, so the officer filing it can see whether it fits before anyone is asked to approve it. This is a read-only preview. The hub checks, it does not commit: it sets nothing aside, and it moves no money. The commitment — the encumbrance — happens on the other half of the rail, on approval, and this page hands the requisition off there.
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 what the available balance is, and reports the fit. The ledger of record remembers; the front door files and previews.
Honestly, where the build is: the submit-and-budget-check flow 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 requisition, worked out plainly
A requisition here is a single record that stands for a single intended purchase. It carries the line items being requested, an account and a fund it draws on, an optional vendor reference, and a total. 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 requests. A line for four hundred and ninety-nine cents is four hundred and ninety-nine cents, filed and totalled as an integer. Rounding drift is not a small bug in a ledger — it is the bug — so the front door never introduces it.
Because the requisition is the record, there is one place a buy-it request lives, and it is the same place the approver reads, the same place the budget check runs against, and the same place a plain-language status is read back from. There is no second copy in a shared drive that drifts out of step with the real thing. When a finance officer files a requisition, the total is checked against the available balance and the record is written; a person can read it back and see, in plain language, exactly where it stands.
The budget check at the front door
Schools keep money in funds against budget authority — the amount an account is allowed to spend. Some of that authority is already encumbered (set aside for approved requests) and some already expended (spent). The plain-language identity the front door reports against is this: budget authority, minus what is already encumbered, minus what has already been expended, equals the available balance. When a finance officer files a requisition, the hub reads that available balance from the canonical general ledger and compares it to the requisition total.
If the requisition fits inside the available balance, the front door records it and says so. If it does not fit — if it would push the account past its authority — over budget is blocked at the front door: the officer is told, plainly and up front, that the request does not fit, rather than filing something that only fails later at approval. Nothing squeaks through to be reconciled next month. And because the whole check is a read, it never quietly changes the ledger; the officer sees the fit, and the money is left exactly where it was.
To be exact about the division of labour: this front door checks the fit and does not commit. Setting the money aside — the encumbrance — is a separate, deliberate step that happens on approval, on the budget-control side of the rail. The two are kept as separate surfaces on purpose, so a preview at the front door can never be mistaken for a commitment.
The finance-officer wall, fail-closed
Filing a requisition is not something a busy office hands around. Only a finance officer can file one or read one back. 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, vendor, and budget data at the database engine — before any application code 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 front door does not file, does not disclose, and does not preview a budget unless the caller is proven to be a finance officer.
The states a requisition passes through
On the submission side a requisition moves from draft to submitted, and then is handed off to the approval side. Reading it back gives a plain-language status a person can act on. There is one state the flow is built not to reach.
Draft
A requisition being assembled at the front door — line items, account, fund, and an optional vendor reference. Nothing is checked against the ledger and nothing is filed until it is submitted.
Submitted
The finance officer filed it. Its total was checked read-only against the available balance, and the record is written and waiting on an approver. This is where a filed run HOLDS on this side of the rail.
Handed to approval
The submitted requisition is picked up on the approval and budget-control side, where a finance officer approves or rejects it and approval encumbers the budget. That step lives on the sibling surface, not this front door.
Paid
Unreachable. There is no pay, expend, or disburse endpoint anywhere in the flow, so nothing can move a run 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. The front door does exactly two things with a requisition: it records it, and it previews the budget fit read-only. It moves no real money, it sets nothing aside, and it only files and checks. There is no pay, expend, or 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.
So this page claims exactly what the front door does and no more: it files a requisition, it reads the ledger to preview whether the budget fits, 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. A filed run holds at “submitted”; disbursement is never reached because it is not built. 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 front door 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 vendor 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 filing also gates reading back.
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 Management?
They are the two halves of one requisition rail. Procurement Center is the SUBMISSION side — the purchasing hub where a finance officer files a requisition that is the purchase request and the budget is checked read-only before it moves. 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 that the requisition is the record?
A requisition is a single record that stands for a single intended purchase — its line items, the account and fund it draws on, an optional vendor reference, and a total in exact integer cents. It is not a note that a purchase order gets typed up from somewhere else later; it is the record the whole rail acts on. There is one place a buy-it request lives, and the approver, the budget check, and the status all read the same one.
Does filing a requisition set money aside?
No. The front door checks the fit and does not commit. When a requisition is filed, the hub reads the canonical general ledger and compares the total to the available balance, so the officer sees whether it fits — but it sets nothing aside and moves no money. The encumbrance is a separate, deliberate step that happens on approval, on the budget-control side of the rail.
What happens if a requisition is over budget?
Over budget is blocked at the front door. If the requisition total would push its account past its authority, the officer is told plainly and up front that it does not fit, rather than filing something that only fails later. Because the check is a read, nothing is changed in the ledger; the money is left exactly where it was.
Can this pay a vendor or cut a check?
No. The front door records a requisition and previews the budget fit. 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. A filed run holds at “submitted”. Money is honest-off by construction, not by a toggle.
Who is allowed to file a requisition?
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 front door: it files a requisition and previews the budget fit, and the canonical ledger of record remembers. 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, vendor, 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.
Is Procurement Center a school, a district, or a nonprofit?
No. Procurement Center is a for-profit software product — a back-office purchasing front door for schools. It is not a school, not a district, and not a nonprofit, and nothing here is a donation. We are precise about the difference because it matters: this is software a school buys, not a charitable gift.
How much does it cost, and can we use it now?
There is no pricing on this page, and not generally, yet. The submit-and-budget-check flow 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 Center is the submission and budget-preview half of the requisition rail. These adjacent destinations cover the approval half and the platform underneath.
procurement.management
The approval and budget-control side of the same requisition rail — where a finance officer approves or rejects a submitted requisition and approval encumbers the budget. This page is the submission and budget-preview half; the two are kept as separate surfaces.
homeroom.software
The school platform this back-office rail runs on. The canonical general ledger the front door previews against lives there, alongside the rest of the platform.
What this page is and is not claiming
Procurement Center — the purchasing-hub front door of 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 front door’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. The requisition is the record, and every amount is exact integer cents. Only a finance officer files one, and a non-finance session reads zero rows at the database engine. The front door checks the budget fit read-only and does not commit — over budget is blocked at the front door, the ledger is never changed by a check, and the encumbrance happens later on the approval side. 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.