Platform · Work

One queue for everything that needs a person.

A proposed accrual, an invoice that does not match, a contract amendment, a hiring decision. Different work from across the financial lifecycle, in one place, with an owner, a due date and the policy that applies. Each item opens the tool that job needs.

Request a demo Where work comes from

Work · assigned to finance · this week

4 items need a person

Opens as · debit and credit workpaper

Proposed cloud expense accrual

DraftedVerifiedApprovedDone

AccountDebitCreditCloud expense 6120$30,000—Accrued liabilities 2150—$30,000

Sources

AWS usage report

NetSuite GL entriesPolicy §4.2

What each kind of work opens

The workflow is unified. The tools are not.

Proposed journal entryA debit and credit workpaper with the calculation, evidence and policy

Invoice exceptionA three-way match: purchase order, receipt and invoice, with the difference named

Contract amendmentOriginal schedule, proposed adjustment and combined waterfall, side by side

Hiring budget decisionThe approved positions and the draft scenarios for each option

Every item carries an owner, a due date, the policy that applies, its status and its financial impact.

Specialised tools

Not every task is a form.

An invoice exception needs the purchase order, the receipt and the invoice side by side. A proposed entry needs debits, credits, the calculation and the evidence. A contract amendment needs three schedules. Work routes each item to the workspace built for it, and the queue stays one list.

Ownership, due dates, status and financial impact on every item
The policy that applies is shown, not assumed
Comments, attachments and history stay with the item

Human authority

Sebastian drafts. People decide. The record shows both.

Routine processing runs under policies the company has authorised. Material judgements, exceptions and protected decisions wait for the right approver. A proposed entry is never shown as posted until the ERP confirms it, and the approval history is part of the workpaper.

Thresholds and approvers per policy, per entity
Every proposal keeps its original version, the revision, and who changed what
The ERP remains the authoritative accounting system

Policy §4.2 · accruals above $25,000 need controller approval

Cloud expense accrual, $30,000

Sebastian drafted the accrual from usage records and posted linesThu 10:12Drafted

Priya requested review as part of the cloud cost investigationThu 10:20Routed

Tomás verified the calculation against the usage report and approvedThu 10:42Approved

Posted to NetSuite as JE-2026-0931. The estimate in the outlook was replaced by the posted amountThu 10:43Posted

Routine processing within an authorised policy runs on its own. Judgements, exceptions and anything above threshold wait for a person.

What changes

What stops happening

P / 1

Approvals scattered across email, Slack and the ERP

One queue, one record of who approved what, linked to the signal or the line that created the work.

P / 2

Preparing the accrual by hand

Sebastian drafts it from usage records and posted lines, with the calculation attached. The controller verifies and approves.

P / 3

A generic task list that forgets the numbers

Every item carries its financial impact, and finishing it updates the outlook or the ledger it belongs to.

Before and after

Finance work, before and after Sebastian

Aspect	Status quo	Sebastian
Where work lives	An inbox, a close checklist, the ERP approval module, and a few Slack threads.	One queue across the financial lifecycle, each item opening its own workspace.
Who prepares	The accountant, from exports and a spreadsheet, the week after month end.	Sebastian drafts the entry, the match or the schedule with evidence; the accountant reviews.
Who decides	Whoever answers first.	The approver the policy names, with thresholds per entity, and the history kept.
What happens after	Someone updates the forecast file, eventually.	The posted amount replaces the estimate in the outlook, and the item links back to its signal.