Spend Management System

01A card is swiped — what must happen before the terminal shows approved?

The network’s authorization request reaches our decision service, every applicable policy and the live budget are evaluated, and we answer approve or decline within the network window — an approval instantly holds the amount against the budget.

02What can an admin actually restrict?

Limits per employee, per team, per merchant category, per single merchant, and per transaction — composed down a company → department → card hierarchy where the most specific rule wins and the most restrictive result applies.

03An employee gets declined at dinner — do they learn why?

Yes, instantly: every decision carries the exact rule that fired, the employee gets a push naming it (“declined: over the monthly travel budget”), and an admin can raise the limit on the spot so the retry succeeds.

04Money approved is not money settled — what tracks the gap?

An approval places a hold for the authorized amount; when settlement arrives days later — often at a different amount (tips, fuel pre-holds) — the hold is replaced by the settled charge and the budget is corrected by the difference.

05How do receipts get attached to transactions?

Employees upload receipts any time; an async pipeline OCRs the image (optical character recognition — reads the text out of the photo) and fuzzy-matches on amount, merchant, and time window — confident matches auto-attach, the rest go to a human review queue, and matching never blocks a swipe.

06Where does all of this end up for the accountants?

Settled transactions land in a spend ledger with GL-code (general-ledger account) categorization and export continuously to the accounting system; month-end reconciliation against network settlement files proves nothing was missed or double-counted.

01How fast must the decision really be?

The decision fits inside our ~500 ms slice of the network’s 2-second window — every input it needs (policy, card state, budget) must be readable locally, because a single cross-region call spends the whole slice at p99.

02The policy engine is slow at the exact moment of a swipe — what happens?

A pre-declared degraded default, not undefined behavior: approve good-standing cards up to a small ceiling, decline the rest, and page a human — the choice is made in a design review, not during the outage.

03Two swipes race for the last $100 of a budget?

Exactly one of two racing swipes takes the last dollar: the budget check and the hold are a single atomic operation on one counter row, never a read followed by a write.

04Someone disputes a decline three months later — can we answer?

Every decision is logged immutably with the rule that fired, the policy version, and the budget state at that instant — the audit log can replay and explain any decision months later.

05A settlement event arrives twice — or never?

Settlement ingest is idempotent by network event id, and month-end reconciliation against the network’s settlement files catches whatever the webhooks dropped — webhooks are fast, files are truth.