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.
- Nobody — the slice becomes an unaddressed task that any Controller Approver or Admin can claim.
Then it deduplicates by person. Case 3 sends no email: an unaddressed slice is watched in the approvals queue rather than mailed to anyone, so a property with no approver named on it relies on somebody opening the queue.
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. Approval mail exists only for a slice with a named property approver. An invoice that is not split, and any slice with no approver named on it, sends no email — those wait in the approvals queue instead. Amount-band approvals are never emailed.
What is asked, and when
| Stage | What runs |
|---|---|
| Property approvals | All of them in parallel. Every approver is asked at the same time. |
| Amount-band tiers | At the same time, on the document total, exactly as they do today. |
Both gates are opened the moment the invoice is sent for approval, and either can be answered first. A controller who signs the document total before any building has answered simply waits for the buildings.
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.
Separation of duties, where a workspace has turned it on, applies to both gates alike: somebody who edited the invoice or sent it for approval can sign neither a property slice nor the amount band. It is off until an Admin turns it on, and it never blocks a rejection.
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 Settings → Split coding, and both are deliberately conservative by default.
| Setting on screen | Field name | Default | The other value |
|---|---|---|---|
| Auto-approve threshold | splitAutoApprove | document_total | per_slice |
| What an approver sees | splitApprovalVisibility | 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. Because that number decides which invoices skip approval entirely, it is governed. The threshold and a property's primary and backup approvers are edited on Properties & entities, and those fields — along with the default GL account and cost center — may only be changed by an Admin or a Controller. An AP Specialist sees them and cannot save them. Each change is written to the audit trail, so "who raised this threshold, and when" has an answer.
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.
The per-property cut of approval SLA compliance
The reports page breaks approval SLA compliance down by building, and on a split invoice one rule decides which building a decision belongs to.
A building is on time when its own approver signed in time. The decision is filed under the property that approver was asked about — the scoped signature — and not under the buildings the money was split across. So an invoice split across three properties contributes up to three decisions, one per property approver, each measured against the deadline that invoice was carrying.
That is the grain a property manager can act on. The alternative, filing the whole invoice under every building that paid a share of it, would report a building as late because somebody at a different building had not signed yet — and there is nothing the first building could do about that.
Two consequences worth knowing:
- The amount-band approvals on the document total are counted too, and they carry no property of their own, so they are filed under the document's property where it has one and under an unattributed line where it does not. The line is shown rather than dropped, so the columns still add up.
- The deadline in play is the earliest of the ones involved, as everywhere else on this page. A building whose own tier allows forty-eight hours is measured against eight when the invoice also touches a building on an eight-hour tier.
A split invoice makes the figure approximate. Sending a split invoice for approval again rewrites its deadline with a fresh clock, so a split invoice that bounced back and was re-sent may be recorded as on time when it was not. The screen says the period is approximate, says how many of the decisions were on split invoices, and shows the rate with those decisions removed so the difference is visible rather than described.
This is our own approval deadline, not the vendor's payment terms: inletAP does not move money and holds no payment terms, so it does not report whether a vendor was paid on time.
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.