Every business with invoices has a second job it never asked for: chasing them. An invoice goes out, and from that moment someone is responsible for remembering it — checking whether it landed, following up when it does not, reading the reply that says "we paid that already," and deciding what to do when it turns out they did not.
Project Atlas is an AI-native accounts receivable platform aimed at that second job. It helps a business recover outstanding invoices, automate the follow-up that surrounds them, understand how customers actually respond, and improve payment velocity — working alongside the accounting system the business already runs rather than asking it to move.
Why I'm building it
Because the gap is structural, not incidental.
Accounting software is very good at the thing it was designed for: creating an invoice, recording it, and reconciling it once money arrives. What it does not do is manage the operational workflow between those two events. That middle stretch — the following up, the chasing, the reading and judging of replies — is where the time goes, and it is largely unowned by software.
So it gets absorbed by people. In a small business that means the owner. In a larger one it means someone whose job is nominally something else. Either way it is repetitive work that consumes attention disproportionate to its difficulty, and it is the kind of work that quietly gets deprioritised until cash flow makes it urgent.
That is also why I am wary of describing this as an AI product first. AI is not the point; it is the mechanism that makes the repetitive half tractable. The design position is narrower and, I think, more defensible: AI removes the repetitive work, and humans stay in the important financial decisions. Deciding when to escalate, when to hold a relationship, when to write something off — those are judgment calls with commercial consequences, and automating them would be optimising the wrong thing.
The problem
An invoice is not a document. It is the start of a process nobody owns.
The process has real steps — send, confirm receipt, follow up, interpret the response, escalate or wait, reconcile — and most businesses run it out of a combination of memory, a spreadsheet, and whoever happens to be conscientious. Accounting software sees the first step and the last one. The middle is invisible to it.
The cost shows up as cash flow, which is the symptom people notice, but the cause is operational. Money that is owed and money that is collected are separated by work, and that work is manual, interruptible, and easy to defer.
The vision
Near-term, the product is about collection: recovering what is outstanding and compressing the time between invoice and payment.
Longer-term it extends past collections into receivables intelligence — treating the accumulated record of who pays, how quickly, under what terms, and in response to what, as something a business can actually learn from. Collections is the entry point because it is the acute pain. The durable value is in what the process reveals once it is instrumented.
Architecture direction
Two positions are settled. The rest is deliberately still open, and I would rather say so than publish an architecture I have not committed to.
It augments the accounting system; it does not replace it. The existing system stays the system of record. This is an integration-first product by design, not by compromise — a business that already runs its books somewhere is not going to migrate them to solve a follow-up problem, and asking it to would be a good way to build something nobody adopts.
AI sits at decision points, with a human retained on the ones that matter. The same constraint I applied to Opsly, for the same reason: automating a process nobody examined first produces bad output faster. Interpreting a customer's reply is a good use of a model. Deciding what that reply means for the relationship is not, at least not unsupervised.
What is not decided — data model boundaries, integration surface, and the deployment shape — is the part that is cheap to decide late and expensive to decide wrong. It will be documented here when it is real.
Current focus
Product design and validation. Specifically: understanding the actual shape of the follow-up workflow across different kinds of business, and testing whether the problem is felt sharply enough to change what people already do.
That is the whole current state, and stating it plainly is the point. There is no built system to describe yet.
Roadmap preview
There is no published roadmap, and that is deliberate rather than an omission.
A roadmap for an unannounced product is a list of promises made before the validation work that should inform them is finished. The direction above is honest about where this is going; the specifics will be published alongside the reveal, when they are commitments rather than intentions.