What it is and who it is for
BKeeping is bookkeeping software built to replace Sage 50 for a working tax and bookkeeping firm. It takes in bank statements and receipts, keeps each client's books separate, and produces the reports the firm works from.
My role
I worked as a bookkeeper at that firm in 2023–2024 and used its expensive software every day. On BKeeping I am the product director and the customer's representative at the same time: I specified the workflows from having done them by hand, directed AI-assisted implementation, tested against the way the firm actually works, and hold the quality bar — including the decision, still in force, that the software does not touch real client data yet.
The problem, and why it was not trivial
A small firm pays a great deal for bookkeeping software that is still slow and awkward for its daily work; from inside the job, I concluded there had to be an easier way. Replacing it is not a matter of screens. Bookkeeping software has to be right, not approximately right: a misread amount, one client's numbers in another's books, or a report that disagrees with its own period are failures a tax firm cannot absorb.
The software also has to run on the firm's own modest Windows PC, and the customer is risk-averse with security as her first concern. Her bar, in her words: "if it could give me my reports and manage the numbers, I could be down for that."
Key decisions and trade-offs
Three decisions shape the product. First, machine-read documents never become bookkeeping entries on their own: statement and receipt PDFs are parsed into drafts, and a named reviewer confirms the fields against the original before anything posts. That is slower than full automation and deliberately so. Second, document reading runs locally with the operating system's own tools rather than an outside service, so client documents do not leave the building to be read.
Third, sign-in is passkey-based — the phone passkey is the default, a hardware security key is the fallback — with no password option to fall back on, because a password fallback would be the weakest door in the building. Clients are kept in hard-separated books with per-client access control, and the system keeps an audit trail of who did what. What was rejected along the way: posting anything to the existing software, offering a password sign-in for convenience, and letting parsed numbers be "repaired" by guesswork — unknown fields stay blank for a person to resolve.
Challenges and how they were handled
Statement and receipt layouts vary, and extraction can miss text entirely, so parsing is checked against a fixed test corpus with one non-negotiable rule: zero silently wrong amounts — an uncertain number is flagged, never smoothed over. Reports are checked by comparing full periods, cash and accrual, against known-good results at zero variance. The build ran under a gate rule I set for the whole program: a piece does not count as finished, and the next does not start, until its checks pass and are written down as evidence.
Results
BKeeping's checks run against synthetic data only, through the period comparisons and parsing scorecard described above. Current status, stated plainly: in development, not in production use, and the firm does not use it for client work. It has not entered testing yet; it is moving quickly through its automated tests and UI/UX expectations and will enter testing soon.
No real client data enters the system until hardware acceptance on the firm's own PC and a proof pass against one real finished Sage period have both happened; neither has yet. The full build became possible in 2026 with AI coding tools and was rebuilt in days — the fastest development I have managed on my own, and the clearest measure in this portfolio of how much faster I can now direct this kind of work.
What I would do differently
BKeeping is so new that I do not know yet what I would do differently; it is no more than a week old.
The BKeeping repository is private; this case study and its screenshots carry the proof instead of a code link.