OnAccount is now available with a standard API library, covering sales, purchases, journals, users, customer and supplier accounts, account balances and statement downloads. Each of those APIs gives an operational system a tested and secure way into your finance data, instead of a one-off build that starts from nothing.
Most finance teams inherit their operational systems rather than pick them, and those systems do their job well enough that replacing them to suit the finance function is rarely the right call. OnAccount is built for that position, working as the finance system alongside whatever already runs your operation and turning its data into billing, receivables and reporting your team can trust. The new API library is what makes those connections quick to build, secure to use, and cheap to keep.
Standard APIs that we maintain and you can customise
Because the APIs are part of the standard product, our team maintains and tests them alongside everything else in OnAccount, and we can customise them to suit how your business works without anyone starting again from scratch. You get the benefit of code that many organisations already rely on, with room for the parts that are particular to you.
This approach significantly reduces the cost and time to integrate into OnAccount by as much as 75% compared with building an API from scratch.
As an example, one of our customers runs three integrations on the standard sales and purchase APIs, bringing in driver payment transactions, warehouse data and sales invoices from three different vendor systems. Each went live in days rather than weeks, and their vendors had less to do because they were integrating against a contract that already existed.
Benefits of the API library to your finance team
Billing that keeps up with the work
Your operational system already knows what you delivered and what to charge for it. The Sales API takes that straight into OnAccount as an invoice, so you bill while the job is still fresh instead of waiting on someone to export it, key it in and run a cycle. You invoice sooner, so you get paid sooner. Nobody re-types anything, which kills off a whole category of typo, and when a customer rings up about an invoice, the detail behind it sits right there on the record.
Costs that land in the right month
In most businesses, what you owe gets worked out well before it reaches finance. A system rates completed jobs for contractors, procurement signs off supplier invoices, an operational system picks up costs as they happen. The Purchase API brings all of it in as payables with no spreadsheet in the middle, so your AP team stops re-keying numbers someone else already calculated and pay runs stop being a scramble at the end of the month. Costs also land in the same period as the revenue they belong to, which is the only way job margin tells you anything worth knowing.
The account position, where the decision actually happens
Finance data doesn't only need to flow one way. The Balances and Statement APIs push it back out, so your dispatcher can check where a customer sits before releasing the next order and your service rep can pull a statement while the customer is still on the phone. You see credit exposure at the point you accept the work, not a month later in an aged receivables report.
It works in the other direction too. Drill back from a posted transaction to the operational record that created it, and a question about an invoice ends at the job or shipment behind it rather than in a spreadsheet hunt. We connected OnAccount to Sandfield's Origin platform this way ourselves, and the same approach applies to whatever you already run.
How the API library is built and secured
Built once and inherited by every integration after it
The library gives each integration a single versioned contract for authentication, validation, error handling and data access. New work connects into that foundation rather than reinventing it, which means faster delivery and fewer places for something to go wrong.
Security is the clearest example. Authentication, input validation and access control are engineered and reviewed once, centrally, then inherited by every integration built on the library. A custom API needs its own security review each time you build one, and that review becomes a cost and a delay your project carries on its own.
Accuracy that holds up to an audit
Financial data is not ordinary data. It has to respect double-entry principles, tax treatment and currency formatting, and it has to stand up to scrutiny months later. The library already understands OnAccount's own rules, so it models and validates each transaction before it posts rather than leaving you to correct it afterwards.
Retry logic handles dropped connections, rate limiting protects the system under load, and error messages say what actually went wrong so a problem traces back to the record that caused it. All of it runs through one audit trail and one permission model, with user roles applied the same way everywhere.
Finance that fits around your operation
The systems running your operation earn their place by doing a job well, and none of that has to change for your finance data to be accurate. OnAccount takes what those systems produce, checks it before it posts, and gives your team one set of numbers to work from, with the detail behind every transaction still traceable back to the job that created it. The library is how that connection gets made, and how it keeps working as your operation and OnAccount both change.
OnAccount is part of the Sandfield family of software products. This article first appeared on the OnAccount website.
