Where the review actually happens today
At most partner-led firms, the pre-bill review runs the same way every month. A biller or a billing coordinator pulls draft invoices out of the time and billing system. A partner, or sometimes a billing manager acting on the partner's behalf, reads every narrative line by line. They are checking two different things at once: does this entry comply with the client's billing guidelines (no block billing, no vague descriptions like "attention to file," no paralegal time billed at a rate the engagement letter does not permit), and does the story the narratives tell actually make sense for what was delivered.
This is slow because it has to be. A client's outside counsel guidelines might run twelve pages. Multiply that across fifteen, fifty, two hundred matters closing in the same billing cycle, and the review becomes the bottleneck between work finished and cash collected. It is also inconsistent, because the person doing the review on a Tuesday afternoon with forty invoices left is not reading as carefully as the person who started at nine with coffee. Entries get missed. Rejected invoices come back from clients weeks later, and the firm eats the write-off or the delay.
An AI billing review workflow does not replace that partner. It reads every narrative the way the partner would on their best day, at the speed of the whole batch, and hands back exactly the lines that need a human decision. That is the system worth describing in plain terms, because the mechanics are what a reader has to approve before it touches real invoices.
What the system actually reads
The system's only source of truth is what the firm already has: time entries as they sit in the time and billing system, the client's outside counsel guidelines where they exist, the engagement letter or fee arrangement for that matter, and the firm's own internal billing policy for anything the client guidelines leave silent. Nothing is invented and nothing is inferred from a pattern the system has seen elsewhere. If a guideline says no more than one timekeeper may bill for attending a hearing without prior approval, that rule has to be entered into the system as text it can check against, not assumed.
This matters because it sets the real precondition for the project. If a client's guidelines live only in a partner's memory of a phone call from three years ago, there is no document for the system to check against, and that gap has to be closed before the system is worth building for that client. The firms that get the most value fastest are the ones that already have guidelines and internal policy written down somewhere, even if it is scattered across contract files and email.
What it checks, and what it produces
For every time entry in a draft invoice, the system runs two separate passes. The first is a compliance pass against the specific client's guidelines: billing increments, caps on travel time, restrictions on administrative tasks, rate caps by timekeeper level, rules on who can bill for internal conferences. The second is a narrative quality pass, closer to what the reviewing partner is actually doing: does the description say what was done in enough detail to survive a client audit, is the time proportionate to the task described, does a cluster of entries tell a coherent story of the work, or does it read like three unrelated tasks billed under one vague line.
The output is not a rewritten invoice. It is a flagged list, sorted by matter, with each flag naming the specific rule or quality issue and pointing at the entry it applies to. A flag for "block billing, guideline section 4.2" reads differently from a flag for "entry says 'review documents,' no indication of which documents or why." The system also proposes a replacement narrative where the fix is mechanical, for instance splitting a blocked entry back into its component tasks based on the timekeeper's own prior entries that day. It does not rewrite and resubmit on its own.
Who looks at it before it counts
Every flag goes to a person before any invoice leaves the firm. For most firms that is still the billing partner or billing coordinator who already owns the matter, just working from a shortlist instead of the full invoice. They accept the system's suggested fix, write their own, or overrule the flag entirely because they know something about the matter the system cannot see, for example that the client pre-approved the extra timekeeper on that hearing by email last week.
That overrule gets logged, with a reason, next to the flag it answers. This is not bureaucratic overhead. It is what lets the firm show a client, or an internal audit, exactly why an invoice looks the way it does, and it is what makes the system's flagging better over time, because disagreements between the system's flag and the partner's call are the clearest signal that a guideline was read wrong or that a rule needs a narrower condition attached.
What happens when it is wrong
Two failure modes matter here and they fail differently. A false flag, where the system questions an entry that was actually fine, costs a reviewer a few seconds of reading and dismissing it. Annoying at volume, but cheap. A missed flag, where a non-compliant entry goes through unchecked, is the expensive one, because it is the exact failure the review was built to prevent, and it only surfaces when the client's own billing audit catches it or the invoice gets rejected outright.
The way to manage that is not to trust the system's judgment calls blind from day one. Early in deployment, every invoice should still get a full human read alongside the system's flags, so the firm can measure how often the system's silence was correct before anyone narrows the review down to flagged lines only. That measurement period is not optional and it is not short. A handful of matters for one month tells you nothing about how the system handles a guideline it has not seen before. The firm needs enough volume, across enough different client guideline sets, to see where the system's checks hold up and where they need a tighter rule written in.
What has to be in place first
Three things, none of them exotic. First, the client guidelines and internal billing policy need to exist as documents the system can be given, not as institutional memory. Second, someone at the firm has to own keeping those documents current, because a guideline changes when a client renegotiates its outside counsel terms, and a stale guideline produces confident wrong answers. Third, the firm needs a clear answer to who has final sign off on an invoice before it goes out, because the system is built around that person's judgment, not instead of it.
None of this requires the firm to already run AI elsewhere. A firm with an existing data or engineering team can plug this into systems it already governs. A firm with none of that can have it built and handed over as a working system rather than a recommendation. What matters more than where the technical capability sits is whether the three things above are true before the first invoice runs through it.
Why narrative compliance, specifically, is underserved
Most billing software on the market today is built around time capture: getting the hours entered accurately, at the point they happen, against the right matter code. That is a real problem and worth solving, but it is a different problem from this one. Narrative and guideline compliance happens after the time is captured, against documents the timekeeper may never have read in full, and it requires judgment about whether a sentence describes the work well enough to survive scrutiny. That is closer to document review than to time tracking, which is closer to work this firm has built before than it looks at first glance.
Where we come in
This is the kind of system Alppoint builds end to end: reading a firm's own guidelines and policy documents, running the compliance and narrative checks against live time entries, and putting the result in front of the person who already signs off on billing, with every override logged. We can take this on as a defined project against one client's guidelines to prove the approach, or work alongside a firm's existing data and engineering team to extend it across the full client book. Either way, the system ships into the firm's own environment and the firm owns it from day one.
