AI Accounts | Payable, Receivable, Invoicing & Verification

The four jobs accounts actually does

There is a lot of noise around AI doing your books, so here is the honest version. An AI does not, and should not, approve payments or sign off a ledger on its own. What it is genuinely good at is the layer underneath, and that layer is bigger than most people assume. Accounts is not one job. It is four, and they are joined at the hip:

Money out. Supplier invoices arrive, get read, get coded to the right entity, job and account, and move through approval to payment.
Money out that should come back. Costs that are recoverable have to be turned into an invoice and actually sent, or the margin quietly disappears.
Money in. What you are owed has to be tracked and chased on a cadence that does not depend on someone remembering.
Money that should not move at all. Every supplier, ABN and bank account has to be verified before payment, because invoice redirection is the fraud that actually lands.

Most teams run these as four disconnected habits held together by a spreadsheet and one person’s memory. Built as one system, the coding done in payable is the same data that raises the on-charge invoice, that ages the debtor, and that the verification checks run against. Each function makes the next one cheaper.

Accounts payable

The deepest and usually the first module, because it is the most painful. What it takes off the desk:

Reading the invoice. Supplier, amounts, line items and addressee lifted off the PDF or the scan, whatever shape your suppliers actually send them in.
Getting it onto the right entity. A bill addressed to an entity you do not run is caught and chased back to the vendor to reissue, rather than quietly coded and paid.
Coding job, account and on-charge. Against your real structure, never an invented one, and never a job that does not exist in the entity being billed.
Accurate from the first invoice. The system arrives already knowing how your business codes, so you are not correcting it for a month before it earns its place. That is the difference between a tool your team adopts and one they quietly stop opening.
Surfacing the ones that need judgement. Anything uncertain, or coded against something retired, comes to a person with the reason attached. Accuracy is prioritised over coverage by design.
Moving it through approval. To your reviewers and approvers, with who signed off and when recorded. The system tracks the routing; it does not decide it.
Posting the finished result. Into your ledger, or into Bedstone’s own, once a person has approved it.

Invoice generation and on-charging

The half of accounts that quietly loses the most money. A cost gets incurred on behalf of a client, a tenant, a project or a related entity, someone means to bill it back, and it never gets raised. Because the coding already happened when the bill came in, the system knows which costs are recoverable and from whom:

On-charge recovery. The on-charge decision made when the supplier invoice was coded becomes the invoice that recovers it. Nothing recoverable sits in a spreadsheet waiting for someone to notice.
Raised on the right entity. Correct legal entity, ABN, address and bank details, with the GST treatment applied per line rather than assumed across the invoice.
Recurring and scheduled runs. Rent, retainers, management fees and periodic recharges are raised on schedule without anyone rebuilding them each month.
On your letterhead. Invoices go out as a document that looks like your business, not a generic system export. Same for statements and remittances.
Straight into the ledger. The raised invoice lands in your accounting system, so the debtor exists the moment it is sent and the chase can start from a real balance.

Accounts receivable

Chasing money is a cadence problem, not an intelligence problem. It fails because it depends on a person remembering, and that person is busy. The system removes the remembering and leaves the judgement:

Aged debtors in one view. What is open, what is overdue, how far, and what is due to be chased next.
An escalating ladder. Each unpaid invoice moves through reminder rungs on a set cadence, from a light nudge to a formal notice, with the tone and timing you set.
Drafted, not fired off. Every reminder is prepared and staged for a person to send. Nothing reaches a customer that nobody read. If you later want a tier of it fully automatic, that is a decision you make deliberately, not a default we ship.
A named human on the thread. A chase from an unattended accounts address reads like a pipe, and people do not reply to pipes. Every reminder carries a real person who can answer, which is what actually gets a payment date back.
Idempotent and self-stopping. A rung is drafted once, never twice. The ladder stops the moment the invoice is marked paid, so nobody gets chased for money they have already sent.
Statements on demand. A current statement per customer, generated from the ledger rather than assembled by hand.

Accounts verification

This is the part most finance automation skips, and it is the part that pays for the build on its own. Invoice redirection, where a supplier’s bank details are quietly swapped for someone else’s, is the fraud that actually lands on Australian businesses, and it lands precisely because the invoice looks completely normal.

We take a defence-in-depth approach. Every payable runs through layered checks before it can be approved: against your own knowledge base of who you deal with and how they normally bill, against official registers and external sources, and against the pattern of everything that supplier has done with you before. The question each layer answers is the same one a careful person would ask if they had the time and could hold the whole history in their head: is this party actually who they say they are, and is this instruction actually theirs.

Where every layer agrees, the invoice moves on. Where any of them disagrees, it stops and a person is told what did not line up and why. Nothing gets paid on the strength of the document looking right, because looking right is the entire method of the fraud.

We do not publish the check list. Which signals we look at, how they are weighted and what makes a combination suspicious is the part that took the work, and it is the part that stops being useful the moment it is public. Under NDA we will walk your finance leadership and your auditors through the whole thing.

Your ledger, or ours

Most businesses come to us already running an accounting platform, and there is nothing wrong with that. We post the finished, coded, approved transaction straight into it and it stays the statutory ledger. Nothing about your lodgement, your payroll or your accountant’s access changes.

The other option is that Bedstone holds the ledger itself. Every invoice in and out, every coding decision, every approval, every payment and every on-charge already lives here, because that is where the work happens. For a business that would rather not pay for and administer a second platform on top of that, the record can simply stay where it was created.

Which one is right depends on what else the accounting platform is doing for you. If it is running payroll and lodging your BAS, keep it and we post into it. If it is functioning as a filing cabinet that someone types into after the fact, you are paying for a second copy of a record you already have. We will tell you plainly which of the two you are on the first call.

What makes it defensible

Finance systems are trusted or not on a small number of properties. These are the ones we hold ourselves to, and the ones worth testing us on:

It cannot invent a value. Nothing is coded to an entity, job or account that does not actually exist in your business. Not an unlikely one, not an approximate match. It either resolves against your own structure or it stops and asks.
It knows the difference between sure and unsure. The system does not hand you one verdict per invoice and hope. Where it is confident it moves; where it is not, that specific thing is put in front of a person with the reason attached rather than being pushed through or thrown back wholesale.
It reads the relationship, not just the document. The most expensive problems in accounts are invisible on a single invoice and obvious across a history. The system holds that history, which is the thing a person under volume cannot do.
A person approves, always. Approval is a human step the system cannot skip, and the routing and sign-off are recorded.
This is where the work happens. Intake, coding, approval, chasing and verification all run here. Where the finished transaction lands is your choice: your existing accounting platform, or Bedstone’s own ledger. Nobody runs two systems in parallel.
An audit trail by default. Every invoice, decision, flag, reminder and approval logged with who, when and why. Defensible to an external auditor on demand.

The internals behind those properties are ours and we do not publish them. Under NDA we will take your finance leadership, your auditors or your IT team through the architecture in full.

Where the human stays in the loop

We are explicit about this because over-promising on finance AI is how trust gets destroyed. The system does not approve payments. It does not decide who signs off. It does not invent a job or an account code to force an invoice through, and it does not pay a bill addressed to an entity you do not run. It does not update a supplier’s bank details on the strength of a letter. It does not send a chase to your customer that a person has not read. Where confidence is low or something looks wrong, it stops and asks. The goal is not to remove the accountant. It is to hand the accountant a clean first pass and a short queue of genuine exceptions instead of a full inbox of raw PDFs and a debtors report nobody has worked. If a workflow you have in mind needs the AI to make the final call on money, we will tell you on the first call that it should not.

What we’ve built

This is not theoretical. The payable side runs in production on real supplier invoices for operators with multiple entities and live job costing. Before it, invoices were coded by hand, entity by entity, against job and account lists held in spreadsheets and people’s heads, with on-charge decisions made line by line. It was slow, and it was where the costly mistakes happened. Now each invoice is read, matched to the correct entity, coded to a job that genuinely exists in that entity’s ledger, scored, and either queued for a quick approval or flagged with the reason it needs a closer look. The first pass stopped being a manual job and became a short exception queue.

The receivables desk we run on our own book. Every invoice we issue is aged, laddered and chased on a cadence, with each reminder drafted and staged rather than fired off, which is the same design we would deploy for you. We were not going to sell a chase system we had not lived with.

The verification layer is not a hypothetical either. It was hardened after a supplier announced a change of bank account mid-queue, which is exactly the moment a normal AP process pays the wrong party. The invoice was held, not paid. That is the behaviour you are buying.

Ledgers and tools we integrate with

We build against the tools you already run, integrating through documented APIs rather than screen-scraping.

The ledger, yours or ours. Whatever accounting platform you run, we post finished, approved transactions in and read your balances back out. Or run Bedstone’s own ledger and skip the second platform entirely. The choice is a configuration decision, not a different product.
Anything else you run. CRM, job management, property or project systems, procurement portals, a database somebody built years ago. If it holds invoices, customers or the data accounts needs, we ingest it. If it is not named on this page that is not a limitation, it just means we have not listed it. Tell us what you run and we will tell you plainly whether it connects.
External sources and registers. Independent verification of the parties you pay, drawn from official and public sources rather than from what the document asserts about itself.
Document intelligence. Extraction of supplier, totals, line items, bank details and addressee from PDFs and scans, tuned for the invoices your suppliers actually send.
The reasoning layer. Production models doing the coding and classification, constrained by your own structure so they cannot output a value your business does not actually have. Model-agnostic, so you are never tied to one provider.
The systems around accounts. Shared inboxes for invoice intake, document stores, approval and notification channels, and the rest of the back office where the data needs to connect.

How an engagement runs

Map the rules. A discovery sprint captures your entities, chart of accounts, jobs, on-charge rules, approval chain, chase cadence and supplier register. You get a recommended architecture and a fixed-price build quote.
Build against your ledger. We build against your real registries and job lists, integrated with your accounting platform, with the approval step and the verification checks designed in from the start rather than bolted on.
Validate on real documents. We run it against your real supplier invoices and your real debtor ledger and tune the thresholds, flags and cadence until it holds up on the work your team actually receives.
Hand over and operate. A working accounts system in your environment, with a runbook and full ownership. Extend to reporting and the rest of the back office as a build or a retainer.

What it costs

Most teams start with a discovery sprint from $7,500 to map the coding, on-charge and chase rules and produce a fixed-price build quote, or an Automate Your Role engagement from $12,000 for a tightly scoped first version covering one of the four functions. A full accounts build starts at $40,000.

After that you choose how you want to hold it:

Monthly subscription. Lower up front, and it covers the running of the thing: hosting, monitoring, model costs, ongoing tuning as your suppliers and rules change, and us on the other end when something looks wrong.
Perpetual licence, purchased outright. You own the deployment. Higher up front and no ongoing licence fee, with support and iteration available separately on a retainer if you want it. This is the right call for groups that want the system on their own infrastructure and on their own balance sheet.

The pricing page covers the full breakdown.

Common questions

Does the AI approve and pay invoices on its own?

No, and that is deliberate. The system reads each invoice and proposes the coding with a confidence score per field. A person reviews and approves the payment. The system tracks the approval chain but never decides it. A wrong payment costs real money, so the design favours flagging for a human over guessing confidently.

Does it send payment reminders to our customers automatically?

Only if you want it to. By default every reminder is drafted and staged for a person to send, so nothing reaches a customer that someone has not read. The ladder escalates on a set cadence, drafts each rung once, and stops the moment the invoice is marked paid.

How do you verify that a supplier is who they say they are?

Layered checks, run before anything can be approved: against your own knowledge base of who you deal with and how they normally bill, against official registers and external sources, and against everything that supplier has done with you previously. Where the layers agree it moves on. Where any of them disagrees it stops and a person is told what did not line up. We deliberately do not publish which signals we use or how they are weighted, because that is the part that stops working once it is public. Under NDA we will take your finance leadership and your auditors through all of it.

What happens when a supplier changes their bank account?

The invoice is flagged and held for a human. A changed account on an otherwise ordinary invoice is the most common invoice-redirection pattern there is, so the system will not quietly pay it. Someone confirms the change with the supplier on a number you already had, and the confirmation is logged.

Your accounting platform, or ours?

Both are options and you pick one. This becomes the primary system your accounts team works in either way: intake, coding, approval, chasing and verification happen here, not somewhere else. If you already run an accounting platform and it works, we post the finished transaction into it and leave it as your statutory ledger. If you would rather not run a second platform, Bedstone’s own ledger holds the record instead. What we are not proposing is two systems running side by side. They do not coexist.

How does it handle multiple entities and projects?

A registry of your group entities and their real jobs is the single source of truth. An invoice is only ever coded to a job that actually exists in the bill-to entity’s own ledger, so no invented job numbers reach the register. Invoices addressed to an unknown entity or a retired code are flagged as critical and routed to a human, never auto-approved.

Can we start with just one part of it?

Yes, and most do. Payable is the usual first module because it is the most painful, and the coding it produces is what makes invoicing, receivables and verification cheap to add afterwards. Starting with receivables instead is reasonable if collection is your bottleneck rather than coding.

Our setup is unusual. Will it handle our rules?

Yes, and that is the normal starting point rather than an edge case. Twenty entities or one. Inter-entity recharges, tenant on-charges, retentions, split coding across jobs, approval thresholds that differ by department and by entity, suppliers who bill under three trading names. The rules are configuration, not a rewrite, so a structure that no off-the-shelf product will fit is exactly the case this is built for. Tell us the messiest part of your process on the first call; that is the part that decides whether this works.

Is this an off-the-shelf product?

No. It is built against your entities, chart of accounts, jobs, on-charge rules, approval chain and reminder cadence. The engine and the patterns are proven in production; the configuration is yours and you own it at the end.

What does an accounts build cost?

A discovery sprint from $7,500, an Automate Your Role engagement from $12,000 for a scoped first version, or a full bespoke build from $40,000. See the pricing page.