How Do You Apply ABA Billing Codes When Multiple Clients Update Their Guidelines?

ABA billing codes provide a shared vocabulary for legal work. They do not create one shared billing policy.

The Uniform Task-Based Management System includes task, activity, and expense codes used in legal e-billing. But firms should also look to individual client requirements: some clients require detailed task codes, some accept phase-level codes, and some do not require activity codes at all.

That distinction matters when several clients issue new outside counsel guidelines at once. The new focus becomes: which version of which client’s rule applies to this time entry, on this matter, as of this date?

For definitions, code examples, entry-level coding guidance, and common coding mistakes, use PointOne’s guide to using ABA billing codes.

The workflow below addresses a different problem: managing several client guideline updates without mixing requirements, duplicating rules, or waiting for invoice rejection to reveal a configuration problem.

The short answer: manage every update as a controlled change

Create a separate change record for each client update. Identify what changed, determine where the change applies, obtain clarification where necessary, configure it at the correct level, test it, and activate it on the stated effective date.

This is a multi-project-management problem. Each client update has its own source document, stakeholders, dependencies, affected matters, effective date, and validation work. A portfolio view helps the billing team coordinate the projects, but it should not collapse their substantive requirements into one rule set.

That approach reflects the underlying reality of Outside Counsel Guidelines (OCGs). OCG compliance requires education, defined processes, and supporting infrastructure.

Firms must translate a high volume of variable requirements into billing controls, while identifying guidelines that conflict with engagement terms or contain outdated information. Each set of guidelines should be reviewed and approved before the matter team is trained. Conflicts should be resolved rather than encoded as assumptions.

1. Open one change record for each client

Start with an intake register that tracks every update without merging the documents. For each client, record:

Keep the source document with the record. Do not replace the previous version without retaining its history. Published client guidelines can carry explicit version and effective-date information. Preserving the prior version lets the firm determine which rules governed work performed before a change took effect.

2. Compare the new version with the one already in force

Do not treat an updated document as an instruction to append every extracted sentence to the existing rule library. Compare versions first. Otherwise, unchanged language can become duplicate rules, while revised language can coexist with the requirement it was meant to replace.

Classify each substantive change so it can be routed to the right owner and system:

• UTBMS code set or code-combination requirements

• Narrative, block-billing, or time-increment rules

• Rates, staffing, and timekeeper approvals

• Expense restrictions and documentation requirements

• Budgets, accruals, and prior-approval requirements

• Invoice format, submission channel, and timing

• Matter-specific exceptions

These categories should remain distinct even when they appear in the same paragraph. A required activity code, an approved timekeeper list, and a rate cap may all affect the same invoice, but they are different controls and may be maintained in different systems.

The comparison should produce three outputs: requirements to add, requirements to revise, and requirements to retire. It should also identify unchanged language, which should not be re-created as a new rule.

3. Resolve ambiguity before configuration

Some guideline language can be translated directly into a test: a required code is present or absent; a disallowed expense appears or does not; a time entry exceeds a stated increment. Other language requires judgment, context, or an approval process.

Before configuring a change, ask:

• Does the new language conflict with the engagement letter, a matter-specific instruction, or another client document?

• Does the document say whether it replaces the prior version?

• Is the effective date clear?

• Is the rule universal for the client, or limited to specified matters, people, offices, or invoice types?

• Can the requirement be tested objectively, or must a reviewer exercise judgment?

If the answer is unclear, record the question and obtain written clarification from the client or the appropriate relationship partner. Do not turn an interpretation into an automated rule merely because the system permits it.

This distinction also determines the appropriate workflow. Objective requirements may be candidates for automated validation. Subjective requirements should be routed to a human reviewer with the relevant guideline language and matter context.

4. Map the change to the correct scope

Once the requirement is understood, map it through the billing environment:

Client → matter → code set → affected timekeepers → billing and e-billing systems

The matter is the operational anchor. It connects a time entry to the client’s rules and to the code set accepted by the destination billing system. Thomson Reuters notes that UTBMS task and activity fields may be optional in Legal Tracker generally but can still be required by a client for particular tasks or cases. UTBMS likewise explains that clients differ in the level of coding detail they require.

Use the narrowest accurate scope:

• A genuine firm policy belongs at the firm level.

• A requirement that applies to all work for one client belongs at the client level.

• A requirement limited to a particular engagement belongs at the matter level.

Matter-specific instructions should take precedence over broader defaults where the governing documents support that result. A client-specific exception should not be promoted to a firmwide rule simply because several clients use similar wording.

5. Build and approve one configuration package per client

A configuration package should contain the approved changes for one client, with links to the source language and the matters affected. It should identify:

• New, revised, and retired rules

• The applicable task, activity, and expense codes

• The level at which each rule applies

• Any exception or required human review

• The effective date

• The approver

Centralizing this work gives the firm a controlled source of truth.

In PointOne, firms can upload guidelines to PointOne Rules, structure rules by client and matter, and apply them automatically during time-entry and pre-bill workflows. The important governance step comes before activation: the firm must confirm that the extracted or configured rule accurately reflects the source document and is assigned to the correct scope.

6. Test the change before it reaches a live invoice

Testing should use matters actually affected by the update and should cover both compliant and noncompliant scenarios. Depending on the rule, confirm that the workflow handles:

• A valid task and activity combination

• A missing required code

• A code that does not belong to the matter’s configured set

• A narrative or block-billing issue

• A permitted exception

• An expense with a documentation or approval requirement

• Transfer of the entry through the practice-management, billing, and e-billing workflow

The purpose is not only to see whether a warning appears. Confirm that the right rule appears for the right matter, that the message gives the reviewer enough context to act, and that an allowed exception is not treated as a violation.

Where possible, test the receiving workflow as well. UTBMS recommends using the receiving system’s testing capability when establishing electronic invoice submissions. A code that is valid in the abstract can still fail if the client, matter, or destination system expects a different field or combination.

7. Activate by effective date, then monitor the first billing cycles

After approval and testing:

1. Activate the configuration on the confirmed effective date.

2. Notify only the timekeepers, billing staff, and reviewers affected by the change.

3. Give them the rule change, affected matters, and required action—not the entire guideline without context.

4. Review affected entries before submission.

5. Audit client feedback, invoice adjustments, and rejections after activation.

Distribute OCGs with new matters and regular updates, then use e-billing tools to manage, track, and audit compliance. Rejections and adjustments should therefore feed back into the change record. They may reveal an overlooked rule, a configuration error, a training issue, or a client interpretation that needs written confirmation.

Do not assume that every rejection proves the timekeeper chose the wrong code. First identify whether the source requirement, system configuration, matter mapping, or entry itself caused the result.

Where automated time capture helps

When billing requirements vary by client, asking every timekeeper to remember every rule is not a scalable control. Automated time capture can move the decision closer to the work by using the selected matter and available activity context to create a draft entry and apply or suggest the configured billing information.

With a platform such as PointOne, the workflow can operate as follows:

1. The platform captures work activity and creates a draft time entry.

2. The matter connects that entry to the relevant client and configured code set.

3. Client and matter-level rules check the draft for applicable requirements.

4. Potential issues are flagged during time entry or pre-bill review.

5. A reviewer confirms the entry and resolves exceptions before release.

This reduces reliance on memory and makes rule application repeatable across matters. It does not authorize the software to resolve contractual conflicts, invent an effective date, or decide a genuinely subjective requirement. Those decisions stay with the firm.

Common mistakes to avoid

Merging every client’s requirements into one master checklist. UTBMS is standardized; client use of it is not. A universal checklist can turn one client’s preference into an incorrect rule for another.

Uploading a revised document as an additional set of rules without comparison. This can leave duplicate requirements or keep superseded language active.

Applying a client exception at firm level. Configure the rule at the narrowest scope supported by the guideline.

Assuming a new guideline applies retroactively. Use the stated effective date or obtain clarification. Preserve the prior version for earlier work.

Automating subjective language as a pass-or-fail rule. Route provisions that require context or legal judgment to a reviewer.

Waiting for rejection to test the configuration. Validate affected matters before submission, then use client feedback as a second control and learning loop.

The operating principle

When several clients update their guidelines, consistency does not mean applying the same codes everywhere. It means applying each client’s approved requirements consistently to the work they actually govern.

A disciplined process—separate intake, version comparison, conflict resolution, precise scoping, controlled configuration, testing, activation, and audit—turns a stack of guideline updates into manageable change projects. Automated time capture and billing-rule platforms such as PointOne can then carry those approved decisions into daily time entry and pre-bill review, where they are most useful.

FAQs about Task-Based Billing Guidelines