Accounting use cases, and how far each one reaches
Every page below follows one workflow into the accounting system your customer keeps, and counts what it can reach there per system. Start with the workflow your product runs, not with the system it lands in.
Start with the workflow your product already runs
Each page follows one workflow into your customers' accounting systems and names the objects, the endpoints and the limits that belong to it.
- Accounts PayablePost bills and payments into your customers' ledger.
- Accounts ReceivableIssue, track and settle receivables in every system.
- Expense ManagementPush expenses into the accounting structure in place.
- Payment ReconciliationDeliver reconciled bookings into any accounting system.
- Bank FeedsPost bank transactions into the customer's ledger.
- Financial Analysis & ForecastingRead the ledger, invoices and accounts a forecast needs.
- Tax AutomationWork with the tax rates and ledgers each system uses.
- Debt CollectionTrack open items and settle them where they already live.
- Business Lending / UnderwritingUnderwrite on accounting data straight from the source.
- FactoringPass invoice and debtor data straight to the financier.
- AI Agents EnablementBuild one agent against every accounting system.
- Customer & Supplier Data SyncKeep customers and suppliers aligned across systems.
- Invoice CreationCreate invoices where your customers already book them.
- Company ConsolidationConsolidate entities that each run their own system.
Every workflow has a widest object and a narrowest one
Each page below names the object its workflow leans on most and the one that decides whether it completes. Put those two side by side and the same shape turns up every time.
- WorkflowAccounts PayableWidestSupplier recordsNarrowestDimensions
- WorkflowAccounts ReceivableWidestCustomer records, readingNarrowestPayment terms, reading
- WorkflowExpense ManagementWidestChart of accounts, readingNarrowestDimensions, reading
- WorkflowPayment ReconciliationWidestChart of accounts, readingNarrowestBank lines, reading
- WorkflowBank FeedsWidestPostings, readingNarrowestMovements, reading back
- WorkflowFinancial Analysis & ForecastingWidestThe chart of accountsNarrowestBank activity
- WorkflowTax AutomationWidestChart of accounts, readingNarrowestTrial balance, for reporting
- WorkflowDebt CollectionWidestDebtor master dataNarrowestOpen items, as an object
- WorkflowBusiness Lending / UnderwritingWidestThe chart of accountsNarrowestThe balance per account, as a report
- WorkflowFactoringWidestThe debtor record behind itNarrowestOpen items as an object of their own
- WorkflowCustomer & Supplier Data SyncWidestCustomers, readingNarrowestCombined list, reading
- WorkflowInvoice CreationWidestCustomer records, readingNarrowestUnits of measure, reading
- WorkflowCompany ConsolidationWidestEach entity's chart of accountsNarrowestA balance per account
The left-hand column is the reason integration demos go well: nearly every workflow opens on an object almost any connected system returns, usually the customer record or the chart of accounts, so the first half of those builds works on effectively every customer you can onboard. That is also why coverage questions asked in the abstract get an optimistic answer, and the exception proves the rule: the one workflow here that only writes has a write route as its widest row, and it opens a good deal lower.
The right-hand column is where a project meets reality, and it is the more useful of the two. The object that gives a workflow its specific value is regularly the thinnest thing it touches. Those rows are not omissions we were talked into publishing. Each of them is the row its page is written around, and where an object has no route at all the page says so directly under its own table. A build plan that reads only the left column will be right about the demo and wrong about the last two weeks.
What follows from that is a checking order rather than a verdict. Take the narrow row of the workflow you need, then look up the systems your customers actually run and see whether that row is supported on those. It is a definite question with a definite answer, and it is usually settled in an afternoon rather than in a pilot. The objects themselves carry the same names and the same shape whichever system answers, which is what one data model is for.
Different workflows, the same connection underneath
Only the objects in the table above are specific to a workflow. Everything a request meets on the way to them is shared, and that is the whole reason the second workflow you build costs a fraction of the first. Access is granted per customer and per system once, through one authorisation flow, and no use case has an opinion about the token handling that follows it. Results come back in whatever size and order each vendor decided, so one paging and filter contract is what lets "read only what changed" mean the same thing on all of them. A large read is an answer on some systems and a job to collect on others, which asynchronous processing hides. And events exist on some of the connected systems and not on the rest, which makes the webhooks page mostly a page about what to do when there is nothing to subscribe to.
The second half of that list is what a workflow meets when something is absent rather than present, and it is the same half those tables come from. A system that does not expose an object answers differently from one that is briefly unavailable, and telling those two apart in your own code for every vendor separately is a project of its own, which is what one error shape removes. A customer whose installation invented a field needs a route past the model rather than a change to it. When somebody asks in three months why a booking looks the way it does, the useful answer is a record of what was called rather than a reconstruction. Where the caller is an agent instead of your own code, the same connection is exposed through an MCP server, and nothing along that path keeps a copy of the books it reads, which the security page sets out in full.
A workflow is not the only way to enter this. Teams that know their market before they know their integration usually get further starting from the industry pages, which collect the workflows one kind of product tends to need together, and the team pages describe the same connection from the perspective of whoever inside your company carries the result. And the case studies are this same material written up by the teams who built on it rather than by us.