An AI agent that gets a business onto FBR digital invoicing

The problem

FBR’s digital invoicing rules say every sale has to be filed electronically and come back with an official invoice reference number. Before a business is allowed anywhere near that, it has to work through a set of prescribed test transactions in FBR’s sandbox and get each one accepted.

That sounds procedural. In practice it is the step where most businesses stall. A submission comes back refused with a terse message about a field nobody on the shop floor has heard of — a tariff code, a rate that depends on the buyer’s registration status, a schedule the item belongs to. You fix one field, resubmit, and a different one fails. For an accountant with a day job, it is a wall.

What we built

Fisco puts an agent in front of that wall. It submits a test transaction, reads FBR’s rejection, works out what the refusal actually means, corrects the value and tries again — on its own. It only stops to ask the owner something when it genuinely cannot infer the answer, and when it does it asks in plain language: what do you actually sell? Not supply a valid HS code.

The difference is not that the software is friendlier. It is that the loop of submit, read the refusal, fix, resubmit stops being the customer’s job.

Once FBR issues a production token, the same engine files real sales and returns the official IRN and QR code for the printed invoice. Invoices reach it three ways, so a business does not have to change how it already works:

• ✍️A simple form — for a business that writes a handful of invoices a day.
• 📗An Excel upload — for anyone whose sales already live in a spreadsheet.
• 🔌Their own POS — through the API, so the till keeps working the way the staff know it.

Where the AI sits

Two different jobs, deliberately kept apart. The agent is autonomous: it is given a task, it works the submit-refuse-correct loop unattended, and the person watching can stop it mid-run at any moment — a human must be able to halt an unattended thing acting under their own tax registration without waiting for it to finish a step. Every limit it runs under lives in one place and is checked before every submission, so “can this run be interfered with” is answerable by reading a single type rather than auditing call sites.

The assistant is the opposite: it never acts on its own, it sits on every screen, and it answers the question the form in front of you does not. No accounting background is assumed, because the person filing is usually the person who made the sale.

The engineering

A single-page application, a separate API, and a relational database behind it, each in its own container. Everything ships through an automated pipeline: a push to the main branch runs the full test suite, and only a green run is allowed anywhere near production.

Two decisions are worth calling out, because they are the sort of thing that only matters later:

• 🔒A strict Content-Security-Policy, and it refuses to be framed by anybody — including our own portfolio page. We could have relaxed that header to get a prettier embed on this site. We did not, because the same host serves the logged-in application.
• 📋Nothing about FBR is guessed. Tax rates and unit-of-measure data are asked of FBR’s own APIs for the specific date and code in question, rather than cached from a table that quietly goes stale.

Why it matters for your project

Fisco is the proof that we can take a regulator’s API — unforgiving, sparsely documented, and consequential when it is wrong — and put a calm interface in front of it. If your product has to talk to a system you do not control and cannot afford to get wrong, this is the work to look at.