AI and Automation

Most software that says “AI” means a feature you switch on. BigLedger’s position is narrower and, for anyone building with agents, more useful: BigLedger is the system of record an AI agent can operate. The whole business — customers, suppliers, items, stock, every document type, the ledger — sits behind one documented REST API, and an agent holding a server-to-server key can read it and write to it today, without a partnership, a pilot programme or a waiting list.

Alongside that, a handful of specific, shipping features use machine learning and rule engines to do work a person would otherwise do by hand: reading supplier invoices and receipts, suggesting bank reconciliation matches, answering on messaging channels, and flagging expense claims for audit.

This page separates the two things a buyer needs to tell apart: what works today, each item linked to the page that documents it in full, and what is in development, which is labelled as such and promises nothing.

What works today

The API is the AI surface

This is the strongest thing on this page and the least discussed. BigLedger’s REST API is not a thin export layer bolted onto a desktop product. The platform’s own applets are API clients — the screens your staff use call the same HTTP surface your agent would — so the API is the product’s primary interface rather than an afterthought attached to one.

The numbers are counted, not estimated: the surface is derived from the backend’s controllers into a route table by a script, and the reference pages are generated from that table. At the commit named in this page’s sources, the backend serves 18,630 routes from 2,216 controllers. Of those, 1,116 routes across 159 controllers carry etl-ep — the server-to-server access endpoint a program calls with an access key rather than a human’s session. That is the agent’s surface, and one generic-document endpoint within it covers 97 document types, from sales orders and purchase invoices to stock transfers and payment vouchers.

So “an agent can run the business” is checkable here rather than asserted: the routes are listed, the reference is generated from them, and you can call them this afternoon.

API Reference

The whole surface by family, how many routes each has, and which have a generated reference page.

Data API

The etl-ep surface in detail: path grammar, resources, paging, envelopes, limits.

Reading documents nobody wants to type

BigLedger runs document images and PDFs through AWS Textract — Amazon’s document-extraction service — and turns what comes back into structured records your staff correct rather than create. Three places use it, and each is documented in full on its applet page.

Supplier invoices. Suppliers e-mail you PDF invoices, or your team uploads them. The platform reads each one — splitting a multi-page PDF and reading it page by page — extracts the header and line detail, and a background matcher ties it to your purchase order, the supplier’s delivery note and your goods-received note by delivery-order number and supplier name, then records whether the documents match, whether the values match, and what the difference is. Nothing posts on its own: finance works the exceptions instead of keying the invoices. See AP Automation.

Expense-claim receipts. A claim item can be configured to require a photographed receipt. The receipt goes to Textract’s expense analysis, and the extracted date, amount, receipt number and vendor pre-fill the claim line — and are then compared with what the claimant typed. See Claim.

Customer receipts, for loyalty points. A member photographs a cash bill from some other business and uploads it. The platform extracts it, matches the merchant and each line against reference data, and once a reviewer finalises the document converts the matched lines into membership points. The merchant and item matching are scored rather than exact, the thresholds are configuration you can see, and correcting one line back-fills every other open document that made the same mistake. See OCR Cash Bill.

What we do not claim. No accuracy percentage appears anywhere on this page. What extraction confidence means, where the thresholds sit and what happens below them is on each applet page, read from the code, because that is the number you can plan around. And Textract is the only machine learning in the platform today: reading documents is where it starts and stops. There is no language model, no speech processing, no image analysis beyond document extraction and no forecasting anywhere in BigLedger — treat any page that says otherwise as a mistake to report.

Reacting to change, instead of asking about it

An agent that polls is an agent that is always slightly wrong and always slightly expensive. BigLedger can POST to a URL of yours when a record changes in a tenant — 54 topics are seeded, covering customers, suppliers, employees, items, inventory, sales documents, companies, branches and membership.

Read Webhooks before you design around it: that page publishes the four guarantees the mechanism does not offer, including that there is one delivery attempt and no retry. The pattern that works is documented there — treat a webhook as a hint, and reconcile on a schedule.

Inside the platform, the same idea runs as a queue of 597 background job processors: e-invoice submission sweeps, import pipelines, marketplace synchronisation, notification pushes, the OCR steps above. A tenant pairs a processor with a cron expression in the Scheduler, so recurring work is configuration rather than a deployment.

Matching work a person would otherwise do line by line

Bank reconciliation. Import the bank’s statement for a period and run the auto-matcher. It scores each unmatched statement line against your cashbook transaction lines using the reference numbers, the transaction dates and the open amounts, weighted by a configuration held on the cashbook itself, and writes the confident pairs as links and the rest as candidates a person accepts or rejects. See Bank Reconciliation.

Automating the contact centre

The Unified Contact Center carries WhatsApp Business, Telegram, Facebook Messenger, Instagram, Lazada, Shopee, e-mail and web chat into one inbox. A bot can be linked to any channel endpoint, and from then on an incoming message on that channel runs a conversation flow — send a message, wait for a reply, branch on what the customer said, wait for a time condition, run an automation rule, or hand the conversation to a human agent.

Be clear what this is. The conversation flow branches on exact and substring text matching and on numeric and date comparison. It is a scripted flow engine, not a language model, and BigLedger does not describe it as one. It is very good at the deterministic half of customer messaging — order status, opening hours, routing to the right team — and it is not a chatbot that reasons.

The whole contact centre is available over the API as well: 35 controller reference pages are generated from the route table at Unified Contact Center API, so an agent of your own can read conversations, post messages and manage endpoints. The bot administration surface exists on the same API; it has no applet reference page yet.

Scoring expense claims for audit

Every submitted expense-claim line gets a risk score and, where something looks amended, a flag with the reason. The score is a set of rules, each adding to the total: the receipt image has already been used on another claim line; the extracted receipt date is more than three days from the date typed, or the extracted amount more than five per cent from the amount claimed; an identical line already exists; or the amount is more than two standard deviations above the average for that claim item.

This is not fraud detection and it blocks nothing. The score and the flags are stored on the claim line. No claim is rejected, held or rerouted because of them. Their one use is that finance can filter for flagged lines when drawing an audit sample for a claim cycle — a human decides. See Claim and Claim Cycle.

Building an agent on BigLedger

If you want to put an agent in front of a BigLedger tenant now, here is the shape of it. Everything in this section already exists; the links are the real documentation, not a summary.

    flowchart LR
  A["Your agent"] -->|"access key<br/>+ tenantCode"| API["BigLedger REST API<br/>…/etl-ep"]
  API --> BL[("The tenant:<br/>entities, items, stock,<br/>documents, ledger")]
  BL -->|"webhook POST"| A
  BL -->|"scheduled pull on<br/>updated_date_from"| A

Get a key. An access key belongs to a user in one tenant and carries that user’s permissions and nothing else — so the permissions you grant that user are the scope of what your agent can do. Integration: Getting Started takes you from nothing to a first real read and write.
Learn the one path shape. Every endpoint is built the same way, and the last segment says who may call it. Data API covers headers, paging, envelopes and limits; Authentication covers the credentials and every failure code.
Find the operation you need. The API Reference is generated from the route table, so a path can only appear on a page if the backend serves it. Start with the module reference for the family you care about.
Write documents through the generic document endpoint. One endpoint, 97 document-type slugs. This is usually the difference between an agent that reads a business and an agent that runs one.
Close the loop with events. Subscribe to the topics you need, then re-read the record through the API before acting on it, and pair every subscription with a reconciliation pull. Webhooks explains why both halves are needed.
Let the platform do the batch work. Where the job is recurring rather than reactive, a scheduled job processor inside the tenant is cheaper and more reliable than your agent waking up to do it.

Two honest constraints. There is no client library and no sandbox tenant today — you work against the HTTP API directly, in a tenant, and the access key is issued for a real user. Both are named in Integrate an External System along with the rest of what BigLedger does not provide, so you can plan around them rather than discover them.

In development

Everything in this section is direction, not product. None of it ships today, none of it has a date, and nothing here should be planned against or written into a contract. It is published so you know where BigLedger is going; the page changes when something actually runs, and not before. What exists today is above.

MCP (Model Context Protocol) — a standard way to expose a system’s data and operations to AI assistants. It would let a general-purpose assistant work with a BigLedger tenant without anyone writing an integration first.
Client SDKs in Python, Kotlin, Java and C# — the REST API wrapped as idiomatic libraries with worked sample applications, so an agent’s author writes business logic rather than HTTP plumbing.
A2A (Agent2Agent) — a protocol for agents built by different vendors to discover one another and collaborate on a task. It would let a BigLedger agent take direction from, and delegate to, agents outside it.
AP2 (Agent Payments Protocol) — Google’s protocol for payments initiated by an agent on a person’s or a business’s behalf, built on A2A. It would let an agent settle a transaction with the mandate and evidence trail a finance system needs.

AP2 is not A2P. AP2 is the Agent Payments Protocol. A2P — application-to-person — is telecom’s term for business messaging, which is a different thing entirely and something the contact centre already does. The two get confused constantly, so on this site AP2 always means the payments protocol and A2P always means messaging.

AIMatrix

AIMatrix (aimatrix.com) is a separate company, working on enterprise AI, that shares a shareholder with BigLedger. That is the whole of the relationship as it stands today: AIMatrix is not part of BigLedger, none of its capabilities are available to BigLedger customers through BigLedger, and nothing on this site should be read as a commitment that they will be. We name it because people ask, and it is better you hear the relationship from us than infer one — and we describe its products no further, because we have not verified them and they are not ours to document. If a joint product ever ships, it will be documented here under its own name, with its own terms and its own support route.