--- title: Designing approval tiers description: How to band invoices by amount, set an SLA and a required number of approvers for each band, and keep the ladder short enough to survive month end section: Tutorials order: 11 --- # Designing approval tiers An approval tier answers one question: for an invoice of this size, who has to sign it and how long may that take. This page is for the controller or principal who owns that answer, and it covers designing a ladder, what the numbers actually enforce, and what happens when a deadline passes. ![The approvals queue grouped into SLA breached, due within four hours, and on track.](/screens/approvals.png "Approvals group by urgency, not arrival order, so the one that is late is the one you see first.") Approval tiers and the rules engine are one feature, and both begin with the Starter plan. A free workspace can read its ladder but not change it, and where no tier covers an amount the invoice needs one approval and is given twenty-four hours. ## A tier is defined by one number A tier is the amount it starts at. Where it ends is not asked for, because it is the next tier's starting amount, and the top tier has no ceiling. That is a deliberate design decision rather than a missing field. If you could set both ends, you could leave a gap between two tiers, or an overlap — and neither failure is loud. An amount that falls in a gap gets the default of one approver and a day; an overlap resolves to the lowest matching tier. Either way your largest invoices would quietly start going through on one signature, and nothing on screen would look wrong. Deriving the bands from the thresholds makes both shapes impossible. Each tier carries three things: | Setting | What it does | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | | Starts at | The amount from which this tier applies. Leave it blank on the bottom tier, so credit notes and zero-value invoices still land somewhere. | | Approvals required | How many _different_ people must approve before the invoice moves on. | | SLA | Hours allowed before the invoice is reported as overdue. | A name and an optional note come with them. The note is a note: it is displayed under the count and it changes nothing. A tier described as "controller plus regional manager" that asks for one approval is released by one signature. ## A worked example A management company running thirty buildings, with an AP specialist, two controllers and an owner who wants sight of anything large: | Tier | Starts at | Approvals | SLA | Reasoning | | -------- | ---------- | --------- | -------- | ------------------------------------------------------------------- | | Routine | — (bottom) | 1 | 48 hours | Landscaping, supplies, the recurring bills nobody argues about. | | Material | 5,000 | 1 | 24 hours | Big enough to check, not big enough to need two people. | | Capital | 25,000 | 2 | 8 hours | Roofing, plant, anything the owner will ask about at the quarterly. | Three tiers, three numbers, and every amount belongs to exactly one of them. An invoice for 24,999 needs one approval within a day; an invoice for 25,000 needs two within eight hours. The SLA gets shorter as the amounts climb, which reads backwards until you think about it. A large invoice is the one with an early-payment discount, a lien deadline or an owner asking questions, so it is the one you want a decision on today. ## Two approvals means two people The required count is enforced where the decision is recorded, not where it is displayed. - The first approval is recorded and the invoice stays in the queue, waiting for a different person. - The same person approving twice is refused. A two-approver tier cannot be satisfied by one determined mouse. - A rejection sends the invoice back for review, and the signatures collected before it do not count towards the next round. Without that, rejecting an invoice would make it easier to approve. Every one of those events is written to the audit trail with the count at the time, so a partial approval reads as "1 of 2" rather than as a button that appeared to do nothing. Who may approve at all is a separate question from how many. An approval has to come from the person the invoice was addressed to, or from a controller or an admin claiming an unaddressed one. See [roles and permissions](/docs/roles-and-permissions) for the full picture. ## What happens when nobody approves in time Nothing moves. This is worth saying plainly, because "SLA" in other products sometimes means automatic escalation. The deadline is stamped when the invoice enters the queue, using the same tier that sets its quorum, so the clock and the signature requirement can never come from different tiers. When the deadline passes: - The invoice is marked as breached and appears at the top of the approvals queue, which groups by urgency: breached, due within four hours, on track. - One email goes out to the members who have that notification switched on. One per invoice, ever — a nag that repeats hourly gets filtered by its recipients within a week. - The invoice does not approve itself, escalate to another tier or change status. An SLA here is a measurement, not an actuator. It tells you which invoices are late; clearing them is still a person's job. ## Segregation of duties, honestly What the product enforces is that a quorum of two is two distinct people, and that approval is restricted by role. What it does not do is stop the person who coded an invoice from approving it on a single-approver tier. If that separation matters to you — and for capital spend it usually should — express it by setting the quorum to two on the tiers where it matters, rather than by assuming the system is doing it for you. Low extraction confidence does not change the tier either. A doubtful read goes to review first, and is matched to a tier by its corrected total when somebody sends it for approval. The tier follows the number you settled on, not the number the model guessed. ## Split invoices: property approvals and amount bands together An invoice [split across several properties](/docs/splitting-invoices) is approved twice over, in a fixed order. First, each property's own approver signs for that property's slice. Those run in parallel — everybody is asked at once — and one person covering three of the buildings gets one task, not three. Then the ladder on this page runs, in series, **on the document total**. A $12,480.00 invoice split four ways is still a $12,480.00 invoice: it is matched to the tier that $12,480.00 falls in, and it needs that tier's quorum after the property approvers have had their say. Two consequences follow, and both are deliberate: - **A large invoice cannot escape the ladder by being split.** The bands are always tested against the total, so twelve small slices do not add up to a small invoice. - **The SLA is the earliest deadline in play.** If one building's tier allows eight hours and another's allows forty-eight, the invoice is due in eight. Reporting it as on track while an approver is already late would make the breach list worthless. Per-property auto-approval, where a property's own threshold is tested against its slice rather than the whole invoice, is a separate setting and is **off by default** for a reason worth reading before you turn it on. See [property approvals](/docs/property-approvals). ## How many tiers is too many Three is usually right. Five is a policy document. Seven is a queue nobody clears in the last week of the month. Every extra tier adds invoices that need a second person who is on site, in a car or on annual leave. The cost of a tier is not the configuration, it is the waiting, and that cost is paid at month end when you can least afford it. Two questions worth asking before adding one: - Would a different person actually decide differently at this threshold? If both approvers would sign anything that reaches them, the tier is ceremony. - Is the SLA one your approvers can meet on a bad week? A four-hour SLA that is breached routinely trains everyone to ignore the breach email, which costs you the one signal that was working. ## Where to go next - [Coding invoices](/docs/coding-invoices) — get the amount and the property right before the ladder sees them. - [Your first coding rule](/docs/first-rule) — including auto-approval on small, high-confidence invoices. - [Property approvals](/docs/property-approvals) — routing a split invoice to the people who own each building. - [Roles and permissions](/docs/roles-and-permissions) — who may approve what. - [The month-end export routine](/docs/month-end-export) — where a long ladder is felt most.