Payment requests with approval, routing to the right finance desk, and mandatory proof of payment. Time-critical ones clear automatically — within a limit and under post-approval.
Web app and Slack bot. One process, one payment history.
Three things break before anything else does.
The requester picks who signs off. From there the system carries the request and will not let a step be skipped.
The standard path for recurring payments inside a business unit's own budget.
For group-level spend and anything not tied to a specific business unit.
The request reaches the second approver only after the first decides. Both decisions stay in the history.
Rejection requires a reason. The reason goes to the requester and stays in the log — a rejected request is never quietly reopened.
One choice in the form determines what has to be attached and which finance desk handles the payment.
Finance works from a queue, not from direct messages. A claimed request is marked as claimed — no one pays the same invoice twice.
Some payments only work inside a window: an ad account top-up, a rate-sensitive transfer, a reserved slot. They get their own mode.
Twenty minutes, an hour, three, or end of day. The deadline is never extended — not by an approval, not by a return to the requester. The finance queue sorts by time remaining, most urgent first.
The request skips sign-off and lands with finance directly. The limit is set per business unit and category, and enforced on the server rather than in the interface.
Once paid, the request is flagged as uncovered and stays with the approver until they confirm or escalate. The uncovered count is visible at all times.
Finance closes a request only together with proof: a statement, a SWIFT confirmation, or a transaction ID. The requester is notified and the history assembles itself.
Filterable register, finance queue, request card with the full chronology, and CSV export.
The same process without leaving the working chat. The bot holds no state of its own — it is a second interface to one system.
Everything listed is included in the licence. There are no add-on modules and no upsells.
Bank, crypto, or other — the choice changes which fields and attachments are mandatory. A request missing them cannot be submitted.
Sequential sign-off with a mandatory comment on rejection. The reason reaches the requester and stays in the log.
Bank payments run through Desk 2 into Desk 1; crypto and other go straight to Desk 1. The route is fixed at submission.
Twenty minutes, an hour, three, or end of day. The finance queue sorts by time remaining, so the burning ones sit on top.
An urgent request under the threshold clears without waiting for an approver. The threshold is enforced server-side and cannot be bypassed from the client.
An automatically cleared request stays with the approver until confirmed or escalated. The count sits in the header.
Statement, SWIFT, or transaction ID. Without an attachment the paid status cannot be set — that is a system constraint, not a policy.
Who submitted, who approved, who claimed it, who paid and what they attached — each with an exact timestamp.
Filter by status, type, category, business unit, and period. CSV export for reconciliation with accounting.
A request stuck in approval or in the finance queue chases itself and escalates upward on configurable thresholds.
Slash command, request modal, approval buttons, finance channel. The bot is a second interface, not a separate system.
Business units, departments, categories, approver assignments, and auto-approval thresholds change without a developer.
The system stores bank accounts, wallets, contracts, and amounts. How they are treated is built into the architecture, not written into a policy document.
Sign-in through Google Workspace or any OIDC provider. Permissions are enforced on the server, not by hiding buttons in the interface.
Invoices, contracts, and proofs live in a closed bucket. Downloads run through short-lived signed links issued only after a permission check.
Account numbers and wallet addresses are excluded from logs and error messages, so they cannot leak through debug output.
History records are never edited or deleted — not by a user, not by an administrator. A payment's history is immutable by design.
TLS on every connection and encryption at rest. Slack is not a storage location: files sent in chat are moved into your own bucket.
Cloud-hosted, or installed on your infrastructure — including a fully isolated environment with no external dependencies.
Retention periods, backup policy, and the data deletion procedure are fixed in the contract and configured to your requirements.
Better said now than discovered during rollout.
The product is responsible for one thing: that no payment is executed without approval and without proof, and that the chain of decisions behind each one can be reconstructed.
A licence per user. Web and Slack are both included — it is one product, not two plans.
Licences are counted by active users per month. Finance, approvers, and requesters all count the same.
We will walk through your current approval route, show how it maps onto the system, and point out where proof of payment goes missing today. Thirty minutes.