Where billing data breaks between the PMS, e-billing platforms, and client systems

A partner logs 2.3 hours on March 14 for "review and revise credit agreement." Ninety days later, a corporate client's accounts payable system rejects the invoice line automatically, no human ever reads the narrative. The reason: a missing UTBMS task code. That one entry, multiplied across thousands of matters, is why law firms write off an estimated 10 to 15% of billed value every year (industry estimate, no single authoritative source, figure varies by firm size and practice mix). This lesson traces the data path of a bill and shows exactly where it breaks.

The four systems a bill actually passes through

Before any dispute happens, a bill's data travels through at least four distinct systems, each with its own schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → and rules.

1. Time capture tool (e.g., Intapp Time, Aderant, or a mobile timer app) where the lawyer logs hours and a narrative.
2. Practice management system (PMS) like Elite 3E, Aderant CompuLaw, or Intapp, which stores the matter, client, and billing rate structure.
3. E-billing platform such as Legal Tracker (formerly Serengeti), Onit's BusyLamp, or CounselLink, which sits between firm and client and enforces coding rules.
4. Client's AP (accounts payable) system, often SAP Ariba or Oracle, which ingests the approved invoice for payment.

Each handoff is a data transformation. Each transformation is a place things fail.

Step one: time entry, the first fork in the road

A time entry isn't just a number of hours. At minimum it carries: matter ID, timekeeper ID, date, hours, rate, and a narrative. Increasingly it also needs UTBMS codes (Uniform Task-Based Management System, a standard taxonomy of legal tasks and activities maintained by the ABA-affiliated LEDES Oversight Committee).

UTBMS has two parts a lawyer must select correctly:

• Task code (e.g., L110 for "Fact Investigation/Development")
• Activity code (e.g., A103 for "Draft/revise")

If the lawyer picks the wrong task code, or skips it because the time capture tool doesn't force the field, the entry is technically valid inside the firm's PMS but will fail downstream. The PMS doesn't validate against the client's specific billing guidelines; it validates against the firm's own rate card and matter budget. That's the first blind spot: the PMS has no visibility into the client's coding requirements.

Step two: the PMS assembles the invoice, blind to client rules

The PMS aggregates time entries into a draft invoice per matter. It applies firm-side logic: discounts, write-downs, trust accounting rules tied to jurisdictional bar requirements (in the US, IOLTA, Interest on Lawyers' Trust Accounts, rules vary by state bar).

But most corporate clients now mandate specific outside counsel guidelines (OCGs): caps on paralegal billing, blocks on first-year associate time, requirements that travel time bill at 50%. These rules live in a document, sometimes a PDF, sometimes a structured guideline file loaded into the e-billing platform. The PMS usually does not ingest OCGs natively. So a fully "correct" invoice by firm standards can still violate client rules the PMS never checked.

Step three: the LEDES export, where formatting kills the bill

To send the invoice to the client, the firm exports it in LEDES format (Legal Electronic Data Exchange Standard), a flat-file specification so client AP and e-billing systems can parse invoices without manual re-entry. Common versions:

• LEDES 1998B: the older, widely supported flat-file format
• LEDES XML 2.1: newer, richer, supports more metadata

Here's a stripped-down look at what a single LEDES 1998B line contains (pipepipeAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →-delimited):

INVOICE_DATE|INVOICE_NUMBER|CLIENT_ID|LAW_FIRM_MATTER_ID|
TIMEKEEPER_ID|TASK_CODE|ACTIVITY_CODE|HOURS|RATE|LINE_TOTAL
20260314|INV-88213|CL4092|MAT-77410|
TK0091|L110|A103|2.3|650.00|1495.00

Format mismatches happen constantly at this step:

• Wrong delimiter or encoding: some client systems expect UTF-8, the firm's export defaults to Windows-1252, special characters (é, ü) in a client name break the parse.
• Field length overflow: a matter ID exceeds the character limit the client's system allows, gets truncated, and no longer matches their internal record.
• Missing required field: the client's OCG requires a task code on every line; the firm's PMS exported a block-billed entry with no code at all.
• Date format drift: MM/DD/YYYY versus YYYYMMDD mismatches silently corrupt date parsing on ingestion.

None of these are "wrong" invoices in a human sense. They're wrong in a machine-parsing sense, which is what actually matters at this stage.

Step four: the e-billing platform, the automated gatekeeper

The invoice lands in the client's e-billing platform (Legal Tracker, Onit, CounselLink, or similar). This is where automated rules engines run before a human ever sees the bill.

Typical automated rejection triggers:

• Task/activity code combination not permitted under this client's OCG (e.g., client bans A103 "draft" time from partners on routine matters)
• Billed rate exceeds the negotiated rate card on file for that timekeeper's level
• Block billing detected (multiple tasks combined into one narrative and one time entry) where the client mandates task-level granularity
• Timekeeper not pre-approved on the matter (a common control tied to conflicts clearance)

This is a genuinely useful resource for seeing how granular these rules get: the LEDES Oversight Committee's published code sets show just how many task/activity/expense code combinations exist and how easy misclassification is.

Rejections at this layer are pure data logic. A $50,000 invoice can bounce over a single mismatched activity code on one $200 line item, and the whole invoice often gets held, not just the offending line, depending on the platform's configuration.

Step five: the client's AP system, the final reconciliation

Once the e-billing platform approves the invoice, it pushes an accepted record into the client's AP system (SAP Ariba, Oracle Fusion, Coupa). This is a separate integration, often via APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → or scheduled batch file, and it introduces one more failure surface: the AP system reconciles against a purchase order or matter budget number that may not match what's in the e-billing platform.

If legal ops set up a budget of $75,000 for a matter in Ariba but the e-billing platform tracks it as $78,000 (a sync lag or manual override never propagated), the AP system flags a variance and holds payment, even though the e-billing platform already approved the invoice. The bill is now stuck between two systems that both think they're right.

Why this matters for firm-level data strategy

Every one of these breakpoints is a data mapping problem, not a legal judgment problem. Firms that reduce write-offs and rejection cycles typically do three things at the data layer:

1. Push code selection upstream, forcing UTBMS task/activity codes at time-entry, not at invoice generation, often via mandatory dropdown fields in the time capture tool tied to the specific matter's client profile.
2. Store OCGs as structured data, not PDFs, so the PMS or a middleware layer can validate against client rules before export, not after rejection.
3. Monitor LEDES export logs as a first-class data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → metric, tracking rejection rate by client, by error type, over time, the same way a firm tracks realization rate.

A short technical resource worth knowing: the LEDES Oversight Committee's site linked above is the canonical, free source for current code tables. Any firm's legal ops or billing data team should be referencing it directly rather than a vendor's simplified summary.

🎬 [VIDEO: "What is LEDES Billing? E-Billing Explained for Law Firms" — youtube.com — a short walkthrough of LEDES file structure and why e-billing platforms reject invoices, aimed at legal ops audiences]

Key Takeaways

• A bill crosses at least four systems (time capture, PMS, e-billing platform, client AP), and each handoff is a format translation, not just a data copy.
• Most rejections are machine-parsing failures (wrong delimiter, missing UTBMS code, field overflow), not disputes over the legal work itself.
• The PMS has no native visibility into client-specific outside counsel guidelines (OCGs); that gap is where "firm-correct" invoices fail client-side validation.
• LEDES 1998B and LEDES XML 2.1 are the dominant export standards; know which one a client requires, since they are not interchangeable.
• Firms that push code discipline upstream (at time entry) and structure OCGs as queryable data, rather than PDFs, cut rejection and write-off rates measurably.