Property approvals
When an invoice is split across buildings, the question "who approves it" gets a second answer. The amount-band tiers still apply to the invoice as a whole; on top of them, each property's own approver signs for that property's slice.
This page is the reference for that routing. For designing the amount bands themselves, see approval tiers; for making the split, see splitting an invoice.
An invoice that is not split routes exactly as it always has. Nothing on this page changes an unsplit invoice.
Who is asked
For each distinct property in the split, InletAP resolves an approver in this order:
- The property's primary approver.
- Its backup approver.
- Your workspace's default approvers.
Then it deduplicates by person.
One person, one task
If one person approves three of the properties on an invoice, they get one task, not three.
This is the most important behavior on the page. A regional manager covering eleven buildings should not receive eleven notifications about one landscaping invoice, and should not have to click eleven times to say one thing. Their task shows every slice they are responsible for and is decided once.
Each approval records the amount that person is actually approving, so a notification can say $4,000.00 of a $12,480.00 invoice rather than quoting a total the approver is not being asked to accept.
The order things happen in
| Stage | What runs |
|---|---|
| Property approvals | All of them in parallel. Every approver is asked at the same time. |
| Amount-band tiers | In series afterwards, on the document total, exactly as they do today. |
The document leaves ready_for_approval only when every property slice has been decided and the tier ladder above it is satisfied. Property routing adds a step; it does not replace the ladder, and it does not let a large invoice out on a small property's signature.
Any rejection rejects the whole document, and the rejecting property is named. There is no partial approval and no partial posting — half an invoice in your ledger is not a state worth being able to reach, and the invoice goes back for review as a whole.
The SLA is the earliest of the deadlines involved. An invoice touching a building with an eight-hour SLA and one with forty-eight is due in eight hours. The alternative — reporting the invoice as on track while one approver is already late — would make the breach list useless.
Two settings
Both live in your workspace settings and both are deliberately conservative by default.
| Setting | Default | The other value |
|---|---|---|
| Split auto-approve | document_total | per_slice |
| Split approval visibility | full | own_slice |
Split auto-approve — and why per-slice is off
A property can carry an auto-approve threshold: small invoices for that building go through without a signature.
With document_total — the default — that threshold is tested against the whole invoice. A $12,480.00 invoice does not auto-approve on a property whose threshold is $5,000.00, whatever the size of that property's slice.
With per_slice, the threshold is tested against each slice. That is the answer a customer usually expects: an invoice split $4,000.00 / $3,200.00 / $2,400.00 / $2,880.00 where every property auto-approves under $5,000.00 would clear without going to four people for amounts none of them would have questioned.
It is off by default anyway, and here is the honest reason:
A $50,000.00 invoice split evenly into twelve slices is twelve slices of about $4,166.67. If every property auto-approves under $5,000.00, that invoice posts with nobody signing anything.
That is not a hypothetical shape. It is what somebody committing invoice fraud inside a business would build, and it is a shape a legitimate invoice almost never takes. Turning per-slice auto-approve on is a real convenience and a real exposure, so it is your explicit decision rather than our default.
If you turn it on, keep the shape in mind rather than trusting the settings to catch it. An invoice whose total would clear an approval tier while every one of its slices sits just below a property threshold is worth a person's eyes, and the split is visible on the document for exactly that reason.
Split approval visibility
full — the default — shows each approver the whole invoice: every property, every amount.
own_slice shows an approver the invoice image and their own allocations, and describes the rest only as a total: "part of a $12,480.00 invoice", with the other properties' amounts withheld.
Most workspaces are a single management company, where full is right and anything else is friction. own_slice exists for joint ventures: three partnerships on one invoice are not necessarily entitled to see each other's numbers, and it should not take a support ticket to arrange that.
Visibility is about display. It changes nothing about what is posted, what is recorded, or what an admin can read in the audit trail.
What is recorded
Every scoped decision is written to the audit trail with the approver, the property, the amount of that slice, and the time. Together with the allocation history, that is the complete answer to "who agreed that this building would pay this much" — which is the question that actually gets asked, months later, by somebody who was not in the room.
Where to go next
- Approval tiers — the amount bands these run alongside.
- Splitting an invoice — how the slices are made.
- Roles and permissions — who may approve at all.
- Audit trail — reading a scoped decision back.