Get started

Vexless documentation

Bookkeeping as a backend. Your software sends the documents it already has and what they mean. Vexless keeps the books, numbers invoices, clears the money, sends payments, and tells you what is paid.

QuickstartSix requests take one customer from nothing to a paid invoice, on a sandbox company. SandboxA company with a simulated bank. Build and test the whole loop without a real one. API referenceEvery endpoint and object, generated from the OpenAPI document.

How Vexless works

Vexless is a headless system of record for bookkeeping, built for software companies whose customers run a business. Your customers use your software. Their books are kept in Vexless without them, or you, doing any accounting.

You send an origin: a sales invoice you issued, a bill your user wants paid, a bank transaction. With it you send an interpretation, the postings it makes. Vexless enforces the ledger rules, numbers invoices, keeps the audit chain, clears open items against each other, sends payments, and reports back through statuses and webhooks.

you or a connection
OriginDeduplicated on content and external reference. Parties resolved or created.
you, an agent or an accountant
InterpretationThe postings the origin makes, and who says so. Versioned; a correction supersedes.
vexless
EntryNumbered per fiscal year. Postings sum to zero, open items carry a party, the period is open.
vexless → you
Settlement and eventsNamed open items cleared against each other. Webhooks fired.

If you do not send postings, the origin waits at RECEIVED until someone does: an accountant in a separate Vexless control surface, an agent, or your own software later. You do not build for that path unless you want it. What it produces reaches you as the same statuses and events.

Vexless does not guess. It does not decide which account a line hits, infer a VAT rate, or work out which invoice a payment clears. Every posting and every allocation is stated by an author the ledger records. Deriving them is deferred until it can be designed deliberately.

Build with Vexless

Guides by the job your software does. Each one ends with the events you will see.

SalesIssue invoices, let Vexless number and reference them, learn when they are paid. PurchasesCapture the bills your customers receive, get them booked, pay them. BankingBank transactions as origins, and how you say what each one clears. PaymentsPay a bill through Vexless. The call is the approval. Accounting & reportingOpen items, balances, reports, and what the accountant does without you.

Understand Vexless

The five things every response is made of.

OriginsThe document behind every entry. One endpoint, four types, one lifecycle. InterpretationsWhat an origin means in the ledger, and who said so. SettlementsHow open items are cleared, and why it is always stated. CompaniesOne per customer of yours: chart, tax codes, fiscal years, connections. PartiesCustomers, suppliers, banks. Resolved from identifiers; never created by you.

Developer essentials

AuthenticationAPI keys, actors, and the headers on every request. WebhooksSigned, at-least-once delivery of every event. IdempotencyRetry any POST safely. ErrorsEvery refusal names the rule it broke. GrantsScopes, and giving an accounting office access. TestingDry runs, the simulated bank, and inspecting what happened.

The contract

First jurisdiction: Finland. The OpenAPI document is the contract; every response is typed there and enforced by the server. The API reference is generated from it.

https://api.vexless.io/v1             # base URL of the service; reserved, not live yet
https://docs.vexless.io/              # these docs
https://docs.vexless.io/openapi.json  # OpenAPI 3.1, fully typed responses; also /openapi.yaml
https://docs.vexless.io/llms.txt      # for agents; /llms-full.txt has the whole reference as text

Current limits

  • Invoice delivery is recorded but not performed: delivery.status stays PENDING_PROVIDER. Render and send invoices yourself for now; the number and RF reference are in the response.
  • Real bank and e-invoice providers are not connected. Send bank transactions and captured bills through the origins endpoint. Payments execute only in the sandbox.
  • Foreign-currency origins need an explicit fxRate; there is no rate source yet.
  • Finland only. The chart of accounts is a minimal one that covers these flows; the statutory report layouts are abbreviated to its lines.

Everything else in these docs is implemented, typed in the OpenAPI document, and covered by end-to-end tests.