Authorize payments
Authorize payments (/payables/authorizations) is the gate into payables: a bill created under it does not enter the official list until someone authorizes it.
It is the guard against an improper entry — nothing a person (or the API) creates as a new obligation turns into money going out without a second pair of eyes. It ships on by default and can be turned off per workspace (see Turn it on or off).
Where it lives
Financial menu → Authorize payments, right below Payables.
The item carries a badge with the number of bills waiting — only the waiting ones, not those already authorized or rejected. The number respects the company selected in the header.
Turn it on or off
Authorization is a workspace setting, and it ships on by default. The control sits in the top-right corner of this screen — the "Require authorization" switch, with an info icon beside it that opens the explanation of the two states.
| State | What happens when a bill is created |
|---|---|
| On (default) | It enters the queue and only becomes official after someone authorizes it — everything this page describes applies. |
| Off | It goes straight to the official payables list, skipping this screen. |
The switch governs new bills only. Turning it off doesn't release what's already waiting, and turning it on doesn't pull already-official bills into the queue; rejected bills stay blocked.
What the gate blocks
While it waits for authorization, the bill exists but sits outside everything:
- Does not appear in the Payables list
- Does not count toward totals, overdue amounts, cash flow, reports, or the Dashboard
- Cannot be sent to the bank
- Takes no manual settlement — "Mark as paid" does not appear
In other words: as far as the rest of the system is concerned, it is not an obligation yet.
What goes through the gate
| Origin | Goes through? |
|---|---|
Form (/payables/new) | Yes |
| CSV import | Yes |
| API | Yes |
| Publishing a draft | Yes — saving as a draft is not a shortcut around it |
| Recurrence installments generated automatically | No |
| Bills imported from Fintera | No |
| Bills that predate the gate | No |
The rule in one sentence: anything someone creates as a new obligation goes through; anything derived, synced, or legacy is born official.
The screen
Three tabs, each with its own counter:
| Tab | Lists |
|---|---|
| Waiting | The queue that needs your ok, ordered by due date |
| Authorized | History, most recent first |
| Rejected | History, most recent first, with the reason |
Columns: Description (with the supplier below it, and the rejection reason on the Rejected tab), Origin, Due date, Status, and Amount. With all companies selected, a Company column joins them.
The search covers description and supplier name.
Origin
Tells you where the bill came from, and it is the field the decision rests on:
- Manual — created in the form or through the API
- CSV import — came from a file
The system also allows for DDA (automatic) and AI agent, but neither of those two origins is recorded today — in practice you will only ever see the two above.
Authorizing
Only on the Waiting tab, by three paths:
- The Authorize button on the row itself
- The row's action menu
- In bulk — tick the rows and use Authorize selected (up to 25 at a time)
The Authorize payment? dialog confirms: "1 payment will be authorized and enters the accounts payable list."
Authorizing does not send anything to the bank. The bill becomes official and enters the list — sending is a separate step, done in Payables. See Bank dispatch.
In a bulk authorization, one isolated failure does not take the others down.
Rejecting
Through the row's action menu — there is no inline rejection and no bulk rejection.
The Reject payment? dialog warns you: "The title is blocked forever and never enters the accounts payable list. Record the reason (optional)."
The reason is optional (up to 500 characters), but it is what the Rejected tab will show later — without it, the history does not explain the decision.
Rejecting cannot be undone through the interface. A rejected bill cannot be authorized afterwards and cannot go to the bank. It stays on the Rejected tab as a record, and nothing more.
The Authorized and Rejected tabs have no actions — they are an audit trail. Clicking the description opens the bill.
Who can authorize
Anyone with access to the workspace. There is no "authorizer" role, and nothing stops whoever created the bill from authorizing it. The gate records who authorized and when; it separates the two moments, not necessarily the two people.
Authorizing is also not exposed in the API — it is a screen-only action.
How the state shows up in Payables
In the Payables listing, an authorized bill shows a round badge with a shield; hover it to read "Authorized". The other states do not appear there — by the gate's own rule, they never reach the list.
Once the bill is sent to the bank, the badge gives way to the gateway status.