The billing agent we built to stop chasing invoices

I've been in operations long enough to know that the hardest problems to solve are the ones nobody talks about in strategy meetings. Revenue, quality, client retention — those get plenty of airtime. The administrative drag that happens between delivering a translation project and getting paid for it tends not to make the agenda.

That changed for us when we finally looked closely at where time was actually going. The answer, in part, was invoicing. Not the invoicing itself, but everything around it: incomplete client records, missing department contacts, routing errors, follow-up emails that could have been avoided. None of it was catastrophic. All of it was cumulative. And it was consistently pulling people away from work that actually required human judgment.

This is the story of how we built a billing agent to address that — what it does, what we deliberately didn't automate, and what we learned in the process.

What was actually going wrong with our billing process

At Tomedes, we handle translation projects for clients across a wide range of industries — legal, medical, technical, corporate. Each client has a different invoicing setup. Some want invoices sent to a general accounts payable address. Others route to a specific department contact. Some have purchase order requirements. A few have invoice formats that don't match our defaults.

Managing those variations manually is manageable when you have a small client base. As volume grows, it becomes a source of friction that compounds quietly. An invoice goes to the wrong contact. A follow-up is needed. A project manager spends time tracking down information that should have been captured at onboarding. A client's payment is delayed not because of anything related to the quality of the work, but because of a gap in administrative data.

None of this is unique to translation. It's the kind of operational drag that affects any professional services company once it reaches a certain scale. What makes it particularly relevant for us is the nature of our work: we operate with teams across multiple time zones, projects that move quickly, and clients who expect the same standard of responsiveness from our administrative processes as from our linguistic ones.

The goal wasn't to fix a broken system. The system wasn't broken. The goal was to eliminate a category of friction that didn't need to exist.

Why we chose to build an agent rather than just automate a form

The obvious solution to incomplete billing data is a better intake form. Ask for more information upfront. Require fields that were previously optional. That approach works up to a point, but it has a fundamental limitation: it puts the burden of data completeness on the client at the moment of onboarding, when they're often least equipped to provide it.

Clients don't always know their accounts payable routing at the point of signing a contract. Department contacts change. Purchase order numbers are sometimes issued only after a project is confirmed. A static form captures what's available at one moment in time. It doesn't respond to what's missing or out of date.

An agent is different. Rather than waiting for a client to fill in a form, an agent can identify gaps in existing data, initiate the right outreach to collect what's missing, and update records accordingly. It can handle the follow-up that would otherwise fall to a person.

We also wanted the system to learn. Not in a vague, aspirational sense — in a concrete operational one. When the agent proposes an action and a human overrides that proposal, the agent should incorporate the feedback. When an outreach strategy produces a response, that outcome should inform future attempts. A static rule system doesn't do that. An agent, designed well, can.

What the billing agent actually does

The billing agent handles the collection of missing client information and the invoicing process for completed projects. At its core, it does three things:

It identifies when billing data is incomplete. Before an invoice can be issued, the agent checks the client record against the fields required to process payment correctly. If something is missing (a department contact, a routing address, a PO requirement), it flags the gap and initiates the appropriate outreach.

It manages the communication around that outreach. The agent doesn't just flag a gap and wait. It composes and sends the relevant message, tracks whether a response has been received, and escalates if necessary. The content of that communication follows templates aligned with our existing client communication standards — the goal is that it reads like Tomedes, not like a system-generated notification.

It updates records and triggers invoice issuance. Once the necessary information is in place, the agent coordinates with our payment processing systems to issue the invoice and update the CRM accordingly.

One design choice worth noting: the agent was built with what we call self-reflection features. Before executing an action, it proposes what it plans to do and surfaces that proposal for human review. This isn't a failsafe for exceptional cases — it's a standard part of the workflow, at least in this early phase.

The part we deliberately kept human

There's a line we drew that I think is important to be explicit about: the agent does not automatically update payment order lines.

This might seem like an obvious extension of what it already does. If the agent is managing invoice data, why not let it update the payment records that flow from that? The answer is that the downstream consequences of an error in a payment order are qualitatively different from the consequences of a gap in a contact record. A missing email address causes a delay. An incorrect payment record can cause a financial error that is significantly harder to unwind.

The principle we applied is that the agent's level of autonomy should be proportional to the reversibility of its actions. Collecting information and drafting communications: automatable. Issuing an invoice against confirmed data: automatable with appropriate checks. Modifying the financial records that determine what we pay and to whom: human review required, at least for now.

This isn't a permanent constraint. As the agent accumulates a track record and we develop more confidence in its judgment, we'll evaluate where that line should move. But starting conservative on financial operations was the right call, and I'd make the same decision again.

What self-reflection means in practice for a financial tool

Self-reflection is a term that gets used loosely in discussions of AI systems. What it means for this agent, concretely, is that the system maintains a record of its proposed actions alongside the outcomes — whether those proposals were accepted, modified, or overridden, and what happened as a result.

When a project manager overrides a proposed action, that override is data. It tells the system something about the gap between its current judgment and the judgment of an experienced operator. Over time, a well-designed agent should close that gap — not by becoming less transparent about its reasoning, but by improving the quality of what it proposes.

This matters for a financial tool specifically because the cost of an incorrect action in billing is not symmetric. A conservative proposal that a human upgrades is a minor inefficiency. An aggressive action that a human has to reverse is a much larger problem. Self-reflection supports the kind of cautious, feedback-driven learning that financial operations require.

We also made sure the agent can be stopped. There's a manual stop control that allows a project manager to halt the automated process for a specific invoice at any point, particularly if a project is cancelled or modified after the billing sequence has been initiated. This wasn't an afterthought, it was a requirement we specified before development began.

What we'd do differently now

A few things.

We'd invest more time upfront in the data quality of existing client records before deploying the agent. The agent is good at surfacing gaps, but the volume of gaps in a mature client database is larger than you expect until you look at it systematically. Running a data audit before launch would have let us calibrate the agent's initial workload more accurately.

We'd also establish clearer protocols earlier for how the agent's proposals are reviewed. In the first weeks of use, there was ambiguity about who owned the review step for different types of actions — billing team, project managers, or the operations lead. That ambiguity created small delays that defeated some of the efficiency the agent was meant to create. Clarity of ownership matters as much as the quality of the tool itself.

And we'd document the override rationale more consistently from the start. The agent learns from overrides, but that learning is richer when the override is accompanied by a reason. Establishing the habit of recording that reason is easier to do at the beginning than to retrofit later.

Why this matters beyond Tomedes

The pattern here isn't specific to translation or to invoicing. Every professional services company has administrative processes that consume human capacity without requiring human judgment. The question of how to redesign those processes for an era of capable AI agents is one that every operations lead is working through right now, whether explicitly or not.

What I'd offer as a takeaway from our experience is this: the value of an agent isn't just in the actions it takes. It's in the structure it creates around those actions — the audit trail, the self-reflection mechanism, the human review layer, the ability to stop it. Those aren't constraints on the agent's usefulness. They're what make it trustworthy enough to use for something that matters.

We built this because chasing invoices is not a good use of anyone's time. We designed it the way we did because financial operations are not a good place to learn from mistakes in production.

The billing agent is running. It's doing what we built it to do. And we're watching it closely, which is exactly what you should do with any tool you've just handed a portion of your financial workflow.