Accounty

1. Personal Starting Point

Accounty started as a personal experiment.

I wanted to see how much of my own company accounting could realistically be automated with AI agents - not as a polished product, but as a practical test with real workflows.

The first use cases were simple but important: creating invoices, archiving incoming and outgoing invoices, matching bank transactions against invoices and credit notes, and automating daily archives for server data.

The goal was not full autonomy. The goal was controlled automation: specialized agents, clear interfaces, auditability, and human oversight where it matters.

The main lesson so far is simple: useful business automation is not one big AI agent. It is a system of smaller workflows that each do one task well.

The cleaned public reference repository is available on GitHub: easyplatform/Accounty.

2. The MCP Zoo Problem

My first approach was to connect one central agent to a small “zoo” of MCP servers. Each MCP server could perform part of the workflow, but the central agent still had to decide the process by itself every time.

In practice, this was too unreliable for business processes.

The agent could use the tools, but it often had to recreate the workflow from scratch: which step comes first, which data is needed, which tool should be used, whether the result is safe to write, and when a human should review it.

That may be acceptable for experiments. For accounting, invoices, documents, and payments, it is too fragile.

The main lesson was clear: reliable automation needs a controlled environment. The core business process should not live only inside a prompt. It should be implemented as a clear workflow with defined inputs, outputs, permissions, and review points.

3. Architecture Idea

Accounty is built around clearly defined subagents.

A subagent is not a free-form chatbot. It is a focused worker with one responsibility: create an invoice, upload a document, retrieve archive evidence, update transactions, match payments, or run an archive workflow.

These subagents are exposed through explicit API endpoints. The agent harness can call them, but the business logic is not hidden inside the harness. The workflow exists as normal software and can be tested, logged, improved, and restricted.

In my setup, the harness is Hermes Agent. Hermes manages the work around the subagents: selecting the right workflow, loading the right skill, asking for approval, coordinating follow-up steps, scheduling jobs, and keeping logs.

This separation is the core of the architecture:

• subagents implement the business process
• the API exposes safe operations
• Hermes orchestrates the work around those operations
• humans stay in control at review and approval points

For me, this became the foundation for more reliable automation: not only better prompts, but better infrastructure around the agents.

4. Business Value

The most useful part of Accounty is not that it “does accounting with AI”. The real value is that it removes small repetitive steps from daily work while keeping the workflow traceable.

Creating invoices becomes faster and more consistent. Incoming and outgoing invoices are archived in one structured place. Bank transactions can be checked against invoices, credit notes, and archived documents instead of searching manually through folders and emails.

This also helps with server maintenance. Daily archiving makes the backup process repeatable, instead of being something I have to remember or check manually every time.

For me, the main benefit is simple: less manual searching, less copy-and-paste work, and better traceability between documents, invoices, payments, and backups.

Another important point: the basic infrastructure can be built with open-source tools. For this experiment, I wanted to keep the setup practical and affordable, without adding new software license costs.

5. Technical Stack

For the technical stack, I tried to keep the setup practical, modular, and mostly based on open-source components.

The central entry point is Hermes Agent. I use it as the agent harness: the place where agents can be started, monitored, scheduled, and connected to human-in-the-loop workflows.

The API layer is built with FastAPI. This gives every subaction a clear HTTP interface, so the automation is not hidden inside one large prompt. Each important task can be called, tested, logged, and reused separately.

For agent workflows, I use LangGraph. This makes it possible to model workflows as controlled steps instead of letting one agent decide the whole process from scratch every time.

For document archiving, I use Paperless-ngx. It provides the archive for incoming invoices, outgoing invoices, credit notes, and other company documents.

For structured information, Accounty uses a database layer for transactions, invoice rows, document references, and links between payments and archived documents.

For server archiving, I use BorgBackup. It handles repeatable archive workflows for the server infrastructure.

For LLM observability, I use Langfuse. Every relevant LLM call should be traceable, because debugging and improving agents is almost impossible without good logs.

6. Privacy, Local Models, and Least Privilege

Accounting data, invoices, bank transactions, contracts, and company documents are sensitive. For this type of workflow, it is not always desirable to send every prompt, document, or transaction to an external model provider.

That is why Accounty also works with open-weight models running on your own hardware. In my setup, this was tested with a local Qwen3.6-35B-A3B model running on an NVIDIA DGX Spark mini computer.

This does not mean that every workflow must run locally. But it gives an important option: sensitive workflows can stay inside your own infrastructure, while the same agent architecture can still use external APIs where this is acceptable.

Privacy is not only about the model provider. It is also about permissions.

In this architecture, Hermes should not run as an administrator, database owner, or root user. The agent gets its own technical users for the systems it needs to access: a dedicated database user, a dedicated API token, and, where server access is needed, a dedicated Unix user on the server.

Each of those users should have only the permissions required for its job. A database user should see or change only the tables, columns, or stored procedures needed for the workflow. A server user should not have broad sudo rights. A Paperless or invoice API token should expose only the operations that the automation actually needs.

Changes should be routed through explicit APIs whenever possible instead of giving the agent broad direct access. For example, linking a generated invoice to a Paperless document should go through a dedicated endpoint such as POST /invoice/assign-paperless-document. Linking a bank transaction to a document can go through a focused endpoint such as POST /fints/paperless.

This has two advantages. First, the API can validate the request and enforce business rules. Second, the agent harness does not need powerful credentials. It only needs permission to call the safe operation that was designed for the process.

For me, this is one of the strongest arguments for the approach. With the right infrastructure, AI automation does not have to mean giving up control over your data or giving an agent unrestricted system access.

7. Skills vs. Subagents

Another important distinction in this architecture is the difference between skills and subagents.

A subagent is the technical worker. It performs a defined action, usually behind an API endpoint. For example, one subagent can create an invoice, another can upload a document to the archive, and another can compare bank transactions with existing documents.

A skill is different. A skill tells the agent harness how to use these subagents correctly. It describes when a subagent should be used, which inputs are required, how the result should be interpreted, and what should happen next.

In other words: the subagent does the work, while the skill describes the process around the work.

For example, an invoice subagent may receive an input file and invoice numbers, create the invoice PDFs, and return a ZIP file. The skill then tells the agent what to do with that result: where the created invoices should be saved, whether they should be uploaded to the document archive, which metadata should be attached, and when a human should review the output.

This makes the setup much more reusable. The same subagent can be called by different workflows, while different skills can describe different business procedures around it.

In Hermes, skills are part of the agent harness concept. They can be discovered and installed through the Hermes Skills Hub, and the skill system is described in the Hermes Skills documentation. For Accounty, this means that skills become the operational knowledge layer between the user, the agent harness, and the specialized subagents.

8. Accounty Subagents

The concrete Accounty implementation is built as a small set of focused subagents around the Spark API. The public repository shows the API entry point in main.py and the agent workflows under src/agent/. The important part is not that each one is spectacular on its own. The important part is that each one has a narrow responsibility and a clear interface.

The FinTS transaction agent updates the transaction ledger. It is exposed through POST /fints/update, fetches recent bank transactions from configured accounts, normalizes them, and stores them without creating duplicates. It does not decide which invoice a payment belongs to. It only makes the bank data available in a structured form.

The Paperless upload agent handles document ingestion through POST /paperless/upload_document. It receives one PDF, extracts the relevant content and metadata, and stores the document in Paperless with useful tags, a correspondent, a date, and a document number when one exists. This turns loose files into searchable archive records.

The document search agent is the read-only archive worker. It uses GET /paperless/search_document and GET /paperless/get_document/{document_id} to find documents by text, tags, or id and to return extracted content when another workflow needs evidence. This is important because matching and review workflows should retrieve archive facts without changing the archive.

The invoice creation agent creates outgoing invoice drafts. It is exposed through POST /invoice/create and receives a timesheet PDF plus invoice numbers. The result is a ZIP archive with generated invoice PDFs and invoice metadata. Related endpoints such as GET /invoice/next-numbers, POST /invoice/create-row, and POST /invoice/assign-paperless-document support invoice numbering, ledger rows, and linking generated invoices back to Paperless.

The transaction matching agent is the reconciliation layer. Its job is to compare bank transactions with invoice rows, credit notes, and Paperless documents. It should prefer exact invoice numbers, amount checks, date proximity, counterparty names, and tags. Confident matches can be linked through a dedicated endpoint; ambiguous matches should become manual-review cases instead of being silently applied.

The backup/archive workflow is the operational safety layer. It is less about accounting logic and more about repeatability: the system should know what needs to be archived, when the archive ran, and whether the result was successful. Even for a small personal setup, this matters because automation is only useful if the underlying data can be recovered.

Together these subagents form a practical pattern: bank data, documents, invoices, matching, and operations are separate concerns. Hermes sits above them as the harness that can call the right action, inspect the result, ask for approval, and continue with the next step.

9. Skills as the Operational Knowledge Layer

Subagents do the work. Skills describe how the work should be used.

That distinction became important in the Accounty setup. The invoice creation endpoint can generate PDFs, but the surrounding process is more than one API call. The agent also needs to know when to stop for review, where documents should be archived, how Paperless results should be interpreted, and which follow-up steps are safe only after approval.

For the public repo I keep the skill layer focused on the workflows that are actually part of Accounty. The skills are in the skill/ folder:

• paperless describes how to upload, search, and read archived PDF documents.
• invoice-stream describes the incoming-invoice path from PDF intake to Paperless and filesystem archive.
• spark-invoice-create describes the direct API call that turns a timesheet PDF into generated invoice drafts.
• timesheet describes the full outgoing-invoice workflow, including validation gates before sheet updates, archive steps, or email.
• invoice-management describes the invoice register rules: snapshot first, write carefully, regenerate reports, and verify changes.
• fints-paperless-matcher describes how bank transactions are matched with archived documents and when manual review is required.
• hook-receiver describes the human-in-the-loop mechanism for approvals and missing information.
• stirling-pdf describes supporting PDF operations, such as merging an invoice with its timesheet evidence.

This is the operational knowledge that makes the system reusable. Without skills, the agent has to rediscover the process every time. With skills, the agent can load the relevant procedure and apply the same rules again: upload first, verify, stop before irreversible actions, preserve evidence, and keep humans in control where the workflow needs judgment.

The skills in the repo are intentionally sanitized for publication. They describe the workflow shape, environment variable names, and API paths, but not private hostnames, tokens, passwords, spreadsheet ids, email addresses, or personal signatures.

10. GitHub / Open Source Part

The open-source value of Accounty is the pattern, not my private accounting data.

The GitHub repository can show how the pieces fit together: a small FastAPI layer, focused agent workflows, Paperless integration, invoice generation, transaction synchronization, matching logic, and Hermes skills that describe the operating procedures around those actions.

The parts that should be public are the reusable interfaces and examples: endpoint shapes, agent responsibilities, skill templates, permission boundaries, and the distinction between subagents and skills. Deployment-specific details belong in environment variables or private configuration, not in the repo.

11. Consulting Angle

Accounty is my personal example, but the pattern behind it is much broader.

Almost every company has workflows like this: documents need to be collected, checked, archived, matched, approved, reported, or transferred between systems. Often these processes are not difficult in theory, but they are spread across emails, folders, Excel files, databases, web tools, and manual checks.

This is exactly where controlled AI automation can help.

The goal is not to replace existing systems. The goal is to connect them better, reduce repetitive manual work, and make processes more transparent. With the right infrastructure, agents can support specific business workflows while still keeping humans in control where it matters.

For me, Accounty is a practical demonstration of how this can look: start with a real workflow, define clear actions, expose safe API operations, use least-privilege credentials, add logging, and then let specialized agents support the process step by step.

That is also the type of work I help companies with: turning repetitive business processes into structured, observable, and controlled automation workflows.