Tagging an expense to a board decision
Back to index The scenario At the March meeting the board voted and approved: "Replace the lobby carpet, up to $40,000." It is closed, it is approved, it is on the record. In April the carpet...
Last updated
The scenario
At the March meeting the board voted and approved: "Replace the lobby carpet, up to $40,000." It is closed, it is approved, it is on the record.
In April the carpet vendor's invoice arrives for $38,400. Your board escalation floor is $10,000, so the expense will route to the board for a vote.
The board is now being asked to approve a thing they already approved. Again. With the same information. And they will approve it, because they already did.
That is what tagging fixes.
What tagging actually does
Tagging an expense to an approved board decision skips ONE thing: the board escalation step at the end of the approval chain.
That is it. That is the whole feature.
What it does NOT skip
The staff approval chain always still runs. In full. Every step.
This is not a way to make an expense approve itself. It is not a shortcut past your controls. Every approver who would have had to sign off on this expense still signs off on it. The person who reviews the invoice still reviews it. The person who checks the GL coding still checks it.
The only thing that is skipped is asking the board to vote on something the board already voted on.
The system says this out loud, on the screen, in the covered banner. It does not ship a bare checkbox and hope you understood.
What qualifies as a taggable decision
The system is strict about this, and it will not let you tag something that does not qualify.
A decision can be tagged only if it is all of the following:
| Requirement | Why |
|---|---|
| Closed | An open vote has not decided anything yet. |
| Approved | A rejected or deferred decision authorizes nothing. |
| On this property | A decision at one property cannot authorize spending at another. This is enforced when you save, not just filtered in the picker. |
| Standalone | A decision that is itself about an expense cannot be used to cover another expense. That is circular, and it is blocked. |
If the decision does not meet all four, the system rejects the tag with a clear error. It does not silently accept it and quietly not apply it.
Important: the picker only shows you qualifying decisions, but the picker is a convenience. The real check happens when you save. You cannot get around it by any route.
How to tag an expense
On a new expense
- Create the expense as normal.
- Find the Require board decision section.
- Under Decision source, choose Tag existing approved instead of the default Create new decision.
- A picker appears with a search box: "Search approved decisions..."
- Each row shows the decision's title, when it was approved ("Approved Mar 14, 2026"), and an Approved badge. Pick one.
- Save the expense.
On an existing expense
The tag rides the ordinary edit journey. There is no separate screen for it.
- Open the expense.
- Choose Edit Details.
- The Require board decision section is there, with the same Decision source control.
- Tag, change, or untag.
- Save.
You can only do this while the expense is still a draft or still pending. Once its board routing has finalized (it is approved, paid, already at the board, voided, or rejected), the tag is frozen and the section is read-only.
Why: retroactively deciding an already-approved expense was "covered" would rewrite history. The window for saying "the board already approved this" is before the routing decision is made, not after.
What you see when it is tagged
The covered banner
Covered by Board Decision: Replace lobby carpet, up to $40,000. Board escalation skipped.
Staff approval chain still runs in full. Board sign-off for this expense is inherited from the tagged decision, approved Mar 14, 2026.
with two buttons: Change and Untag.
Note the tone: this banner is informational and positive, not a warning. Coverage is a legitimate, governed state, not a problem.
Change clears the tag and drops you back into the picker, so re-selecting is a deliberate act rather than a silent swap.
Untag removes the tag entirely. The expense routes to the board normally from then on.
The chip
On the expense drawer's header and on the pending expenses list, a tagged expense carries a Board-covered chip, so you can see at a glance which expenses are riding on a prior decision.
The empty state
If the property has no qualifying decisions yet, the picker says so rather than showing you an empty box:
No approved decisions yet for this property
Once a board decision is closed and approved, it will appear here for tagging. For now, create a new one to route this expense to the board.
with a Switch to create new decision button. It is never a dead end.
If your search finds nothing, it says "No approved decisions match that search" instead. Different problem, different message.
The stale coverage warning
Here is the interesting case.
You tagged the expense to a decision. Later, the board re-opens that decision, or it gets deferred, or the vote gets changed to a rejection.
The expense's coverage is now stale. It is pointing at a decision that no longer approves anything.
The system tells you, with a warning (not the calm info tone of a healthy coverage):
Covering decision is no longer approved. Board routing will re-evaluate on next action.
Replace lobby carpet, up to $40,000 is no longer in an approved state. This expense will be re-routed to the board (or re-checked against another approved decision) the next time it is saved or submitted.
with two buttons: Tag another decision and Untag.
On the pending list the chip changes from Board-covered to Coverage stale.
What actually happens with stale coverage
The expense routes to the board normally on its next action. The coverage stops applying the moment the decision stops being approved. There is no window during which a revoked decision keeps authorizing spending.
Past skips are not undone. If an expense already went through with a covered skip, back when the decision was approved, that skip stands. It was legitimate at the time. The system does not retroactively rewrite a decision that was correct when it was made, and it does not go back and un-approve things. That would be worse, not better.
So: coverage is checked fresh, every time it matters. Never cached, never assumed.
Recurring expenses and tagging
A recurring contract's occurrences inherit the coverage from the contract.
If the contract is covered by a board decision, every occurrence it generates is covered, not just the first one.
And if the coverage is later cleared (for example by an amendment to the amount, which always clears coverage), future occurrences are not covered, and they route to the board normally. The occurrences read the contract's current state, not a snapshot from whenever the contract was set up.
Why an amendment clears the coverage: the board approved a specific thing at a specific number. Change the number and you no longer have their blessing for the new one. Dropping the coverage is the honest behaviour.
What you cannot do
- You cannot tag a pending decision. The board has not decided yet.
- You cannot tag a rejected or deferred decision. It authorizes nothing.
- You cannot tag a decision from another property. Blocked at save.
- You cannot tag a decision that is itself about an expense. Circular. Blocked.
- You cannot tag an expense that has already been approved or paid. The window has closed.
- You cannot manually spin up a redundant board decision for an already-covered expense. The system blocks that too, so you cannot accidentally get the board voting on it after all.
- Board members cannot set or clear the tag. This is a governance field, and the people who benefit from the skip are not the people who authorize it.
The honest summary
Tagging is not a shortcut. It is a way of not wasting the board's time on a question they already answered, while leaving a clear record of which answer you are relying on.
If you find yourself tagging expenses to decisions that do not really cover them, you are not saving time. You are creating an audit finding.
What the system records
Every tag, every change of tag, and every untag is recorded, once, with your name and the time. Every board escalation that was skipped because of a coverage tag is recorded, naming the decision that authorized the skip. So the question "why did this $38,400 expense never go to the board?" always has an answer, and the answer is a specific board decision on a specific date.
The recurring-inheritance copy is deliberately not recorded as a tagging action, because nobody performed one: it is the contract's state propagating, not a person making a choice.