What Is an Accounting API? A Plain-English Guide for Platform Builders
A plain-English definition of the accounting API, what separates it from a tax API or a payments API, and what to check before you build against one.
An accounting API is an interface that lets one program keep another program's books. Your software sends a financial event over HTTP. The API turns that event into balanced double-entry journal entries against a chart of accounts, stores them so they cannot be silently changed, applies the tax treatment, and gives you back reports, documents, and exports through the same interface.
That definition does most of the work. Everything else in this article is a consequence of it.
The one-sentence version
An accounting API accepts financial events from your application, converts each one into a balanced journal entry, stores it immutably with its tax treatment and supporting evidence, and exposes the resulting ledger, documents, and reports as programmable endpoints.
If a product calls itself an accounting API but does not produce journal entries, it is something else with a good name. That is not necessarily bad. It just means it will not do the job you are about to ask of it.
What an accounting API is not
Four adjacent product categories get confused with accounting APIs, usually late in a project.
| Category | What it does | What it does not do |
|---|---|---|
| Tax calculation API | Returns the correct rate or tax amount for a transaction | Keep your books, or store the evidence behind the decision for the retention period |
| Payments API | Moves money between parties and reports on those movements | Record commission earned, VAT owed, or the liability to a seller between payment and payout |
| Unified or aggregator API | Reads and writes data in your customer's existing accounting software | Act as the system of record; your books live in whichever tool each customer already uses |
| Reporting or BI API | Reads figures out of an existing ledger and visualizes them | Create the entries the figures are derived from |
Each of those has real uses. A platform that needs to be the system of record needs the accounting API underneath them, not instead of them.
The five things an accounting API has to do
1. Record balanced entries. Every event becomes debits and credits that sum to the same figure. When a buyer pays €100 on a marketplace that takes €15 commission, the entry debits a clearing account €100, credits a seller payable €85, and credits commission revenue €15. This is not bookkeeping ceremony. It is a structural check that catches whole classes of integration bugs before they reach a report.
2. Keep history. A posted entry is not edited. A mistake is corrected by a reversal plus a corrected entry, both linked to the original. Closed months are locked so nothing new can be dated into them.
3. Resolve tax. For EU trade, that means place of supply, reverse charge, VAT identification numbers checked against the official registry, and the evidence that justified the decision, all stored alongside the transaction rather than discarded after the calculation.
4. Reconcile against outside money. Books that never meet a bank statement are a guess. The API has to ingest statements or provider settlements and match them against what was recorded.
5. Export. Reports, documents, and audit files, in formats a human accountant and a tax authority accept.
A product that does the first three but not the last two will still leave a person doing spreadsheet work every month.
What a call actually looks like
The mechanics are simpler than the accounting. In Nordlet's API every operation is an RPC-style POST with a predictable shape:
POST /v1/{module}/{resource}/{action}
Authorization: Bearer <api key>
Idempotency-Key: <your event id>
You create a sales invoice, then issue it. Issuing is the moment the accounting happens: the document gets its gapless number, the balanced journal entry posts, and the VAT lines are recorded with it. Your platform never assembles debits and credits by hand.
Three details in that snippet matter more than the endpoint name:
- The scope on the key. A key carries permissions like
sales:write, so an integration gets only the access it needs. - The idempotency key. Retry the same request with the same payload and you get the stored response back rather than a second invoice. Send the same key with a different payload and the request is rejected with
idempotency_key_reuserather than quietly accepted. - Money as strings. Amounts are decimal strings, not floating-point numbers, because floats lose cents in ways that surface at year-end.
Where it sits in your architecture
Your application stays the front end and the source of business events. The accounting API becomes the financial system of record behind it. The flow is usually:
- Something happens in your product: an order, a refund, a payout, a subscription renewal.
- Your backend calls the accounting API with the event and an idempotency key.
- The API posts the journal entry, applies VAT, and returns identifiers you store against your own records.
- A webhook such as
sale_invoice.paidtells your system when state changes, so you react to events instead of polling for them. - Bank transactions arrive through a bank feed or a statement import and are matched against the recorded documents.
- At period end, reports and tax registers are generated from the same data, and the closed month is locked.
Nothing in that list requires a human to open an accounting application. That is the point of the category.
How it compares to the alternatives
| Approach | Effort to start | Audit position | Scales with transaction volume |
|---|---|---|---|
| Spreadsheets and manual entry | Lowest | Weak; history is editable | No |
| Accounting app plus CSV exports | Low | Depends entirely on discipline | Poorly; someone imports files |
| Aggregator API into each customer's own books | Medium | Inherits whatever the customer's tool does | Yes, but you never own the record |
| Embedded accounting API | Medium | Strong if the ledger is immutable and periods lock | Yes |
| Build your own ledger | Highest | Strong only if you also build the controls | Yes, and you maintain it forever |
Building your own is a legitimate choice for some teams. It is covered in more detail in our build-versus-buy guide for marketplaces.
What to check before you build against one
- Is the balance derived or stored? Ask whether a seller balance is a query over journal lines or a column someone updates. Only one of those survives an audit.
- What happens on a retry? Send the same request twice and count the entries.
- Can you edit a posted entry? The answer should be no, with a documented correction path.
- Does a locked period actually reject a posting? Try it in a sandbox. Nordlet returns
409for a posting dated inside a locked period. - How is money represented? Decimal strings or integer minor units. Never floats.
- What is in the audit record? Actor, action, entity, and the change itself, queryable rather than buried in log files.
- What are the rate limits? Nordlet allows 300 requests per minute per API key and reports your remaining budget in response headers. Whatever the number, know it before you design your sync.
- How do you get your data out? Reports, documents, and journals, in formats you can hand to an accountant.
Every one of those is testable in an afternoon against a sandbox company. Vendor feature lists are not evidence; a reproducible test is.
FAQ
Is an accounting API the same as accounting software?
It is accounting software with the interface moved. Traditional accounting software puts a person in front of the ledger; an accounting API puts your code there. The underlying obligations, double-entry structure, and reports are the same.
Do I still need an accountant if I use one?
Yes. An API automates recording, calculation, and reporting. It does not make judgment calls about classification, provisions, or how a specific contract should be treated, and in most countries it does not sign or file your statutory accounts.
Can I use an accounting API without understanding double-entry?
Partly. A good API constructs the journal entries for you from a business document such as an invoice. You still need to understand what the accounts mean when you read a report or explain a balance to an auditor.
What is the difference between an accounting API and a ledger API?
A ledger API records balanced movements between accounts. An accounting API does that and adds the statutory layer on top: documents with legal numbering, VAT treatment, tax registers, fixed assets, period close, and the reports a jurisdiction expects. Every accounting API contains a ledger; not every ledger is an accounting system.
How long does integrating one take?
For a first working flow — create a customer, issue an invoice, receive a payment, see the journal entry — plan days rather than weeks with a typed SDK and a sandbox. A production integration covering refunds, corrections, multi-currency, reconciliation, and period close is a larger piece of work, and the honest estimate depends on how many of those cases your product actually generates.