Designing approval tiers

An approval tier answers one question: for an invoice of this size, how many people have to sign it, and how long may that take. This guide creates one. The explanation of what the numbers enforce, and of where a ladder goes wrong, is underneath the procedure.

Before you start

You need the Admin role. Only an Admin can add, edit or delete a tier. A Controller Approver can read the ladder and cannot move it. That is deliberate rather than an oversight: anyone who can edit the ladder can lower the required approver count to one and then approve alone, so whoever holds this holds the whole quorum. If you are the controller who owns the policy, design the ladder here and have an admin enter it.

You need the Starter plan or above. Approval tiers are part of the rules engine, and the two are sold and gated as one feature. Reading the ladder is free on every plan; changing it is not. Where the role or the plan is missing, the Add tier button is disabled and the reason is printed under the card heading.

Decide the numbers before you open the dialog. A tier is a name, the amount it starts at, a number of approvals and a number of hours. The worked example further down is a reasonable shape to start from.

You already have a ladder. A new workspace is created with one tier, "Standard approval": no floor, one approval, 24 hours. That is not a placeholder — it is what the approve path does anyway, written down where you can see it.

1. Open the approval policy tab

Go to Settings → Approval policy. The first card is Approval tiers. It shows how many are configured, then the ladder itself: Tier, Amount range, Approvals required, SLA.

Read the ladder before you add to it. A tier is defined by the amount it starts at, so a new row also changes where the row below it ends.

2. Press Add tier

Add tier is at the top right of that card. It opens a dialog called New approval tier.

3. Fill in the four fields

• Name. What the tier is called. It appears in the ladder, in the approvals queue, and on the invoice itself when the invoice is matched to it.
• Starts at. The amount this tier applies from. Leave it blank on the bottom tier, so credit notes and zero-value invoices still land somewhere. Where the tier ends is not asked for: it ends where the next tier starts.
• Approvals required. How many different people must approve. Between 1 and 10. A quorum above ten is refused, because a typed 200 would wedge every invoice in the queue.
• SLA (hours). A whole number of hours, between 1 and 8,760, which is a year. Zero is refused: a tier of 0 hours is overdue the moment an invoice arrives.

A Note field comes with them, and it is optional. The note is a note: it is displayed under the approvals count and it changes nothing. A tier described as "controller plus regional manager" that asks for one approval is released by one signature.

4. Save it

Press Add tier in the dialog. Anything wrong is listed inside the dialog as sentences — a missing name, a fractional SLA, a count above ten, or another tier that already starts at that amount. Two tiers may not start at the same amount: there is no honest ordering between them, so the save is refused rather than resolved by row order. The browser checks these while you type and the API checks them again, so a stale tab cannot slip one through.

What you should now be looking at: the Approval tiers card with your tier in the table, a confirmation reading "Approval tier added", and an Amount range column that you never typed. The range is derived. Every write re-stitches the whole ladder from the starting amounts, so the tier numbers and the bands of the rows around yours are redrawn in the same save.

5. Prove it is the ladder in force

Two checks. The second is the one worth doing.

Open Approvals. The Why these need you card lists the ladder rung by rung — name, band, approvals required, hours to decide — and it is built from the workspace's stored policies rather than from anything typed into the screen. If it says the workspace has no approval tiers, nothing was saved.

Then open an invoice whose total falls in your new band, from the Inbox. Under Routing & approval the panel names the tier — "Policy Capital applies to $28,400.00 — 2 approvals required within 8h." The panel is only allowed to name the tier while its approver count agrees with the quorum the server is enforcing on that document; when the two disagree, the name is dropped and only the enforced number is stated. A named tier is therefore evidence that both sides are reading the ladder you just saved.

Editing a ladder later affects invoices already waiting. The number of signatures is derived each time the invoice is read, so a change shows up on the next reload. A deadline does not move: it is stamped once, when the invoice enters the approvals queue.

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 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.

A worked example

A management company running thirty buildings, with an AP specialist, two controllers and an owner who wants sight of anything large:

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.

Each approval 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. A rejection is recorded with its comment and, on a split invoice, the property that refused; it does not carry a count, because a rejection ends the round rather than advancing it.

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 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 moves to the top of the approvals queue, which groups by time left: Overdue, due within 4 hours, on track, no deadline. Nothing is written on the invoice itself — the grouping is computed from the deadline each time the queue is drawn.
• One email goes out to the members who have that notification switched on. The sweep runs every fifteen minutes, and one email covers every invoice that went past its deadline in the same pass: the count in the subject line, up to twenty of them named oldest first, the rest counted. Each invoice is named once, 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.

How lateness is reported

Approval SLA compliance is one comparison: the moment a decision was recorded, against the deadline the invoice was carrying. On or before is on time; after is late. It measures our own approval deadline, not the vendor's payment terms — inletAP does not move money and does not hold those terms, so it cannot report that number and this one is not a substitute for it.

Three properties of the figure, so it can be read rather than trusted:

• An invoice with no deadline is in neither column. A document that never entered the approvals queue, or one that arrived before your workspace had any tiers, carries no deadline. Those decisions are reported separately as "no deadline", in neither the numerator nor the denominator.
• The percentage is withheld below twenty decisions, and the counts never are. "3 of 5 decided inside the deadline" is true at any size; "60%" is not, because one more decision moves it twenty points.
• A count of past-deadline invoices is written as "at least". The sweep that records them runs every fifteen minutes and only sees invoices still open, so one that passed its deadline and was approved eleven minutes later never produced a row. It is a lower bound rather than a census.

A split invoice's deadline is rewritten each time it is sent for approval again, so its clock can be restarted; Reports marks such a period as approximate and shows the rate with those decisions removed. Metrics reference defines every figure on that page exactly.

Separation of duties, honestly

What the tiers enforce is that a quorum of two is two distinct people, and that an approval nobody was named on can only be claimed by a Controller Approver or an Admin. An approval addressed to a named person is theirs to decide whatever their role and whatever the amount.

What the tiers do not do on their own is stop the person who coded an invoice from approving it on a single-approver tier, and neither do the roles. The control for that is separation of duties, a workspace setting an Admin turns on in Settings → Approval policy, on the same tab as the tiers; it is off until they do. With it on, whoever edited the invoice's amounts or coding, or sent it for approval, cannot approve it — whatever their role, whatever the tier, Admins included. See roles and permissions for what counts as editing.

Setting the quorum to two on the tiers where it matters is still worth doing, and the two controls answer different questions: the tier asks for a second judgment on the amount, the setting removes the preparer from the list of people who can give it.

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 is approved twice over: once per property slice, and once against the amount band for the whole invoice. Both are asked for at the same moment, either can be answered first, and the invoice is released only when both are satisfied. Each property's own approver signs for that property's slice, and those run in parallel — one person covering three of the buildings gets one task, not three.

The ladder on this page runs 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 as well as every property's signature. So a large invoice cannot escape the ladder by being split — twelve small slices do not add up to a small invoice. Its deadline is the earliest one in play: if one building's tier allows eight hours and another's allows forty-eight, the invoice is due in eight.

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.

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, and that cost is paid at month end when you can least afford it.

Two questions before you add 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 deadline that passes routinely trains everyone to ignore the email, which costs you the one signal that was working.

Where to go next

• Coding invoices — get the amount and the property right before the ladder sees them.
• Your first coding rule — including auto-approval on small, high-confidence invoices.
• Property approvals — routing a split invoice to the people who own each building.
• Roles and permissions — who may approve what.
• The month-end export routine — where a long ladder is felt most.