The Real Scope of Connecting Time and Billing Systems to Everything Else

At most firms, 3E, Aderant, or Elite Enterprise is the system of record for clients and matters, and the financial functionality is built on top of that. Any integration reading authoritative client or matter data is therefore a billing system integration, whether or not it was scoped as one.

The billing system holds the authoritative client list, the matter list, the responsible attorney, whether a matter is open, and the practice group and office it belongs to. Populating a portal, feeding a CRM, provisioning a DMS workspace, or driving a reporting layer all read from it. That centrality is the source of the scope.

Matters have a lifecycle, and records are the wrong abstraction

Integrating two enterprise systems normally means agreeing on entities and synchronizing them. Billing systems complicate that because the central entity is not static.

The states a matter passes through:

• Opened provisionally, before the client is fully onboarded
• Carrying a temporary number, renumbered after conflicts clearance
• Transferred between responsible attorneys or between offices
• Closed, where closed means queryable and inactive rather than deleted
• Reopened, which happens
• Created purely for administrative purposes, and never intended to reach a downstream system

An integration that treats matters as rows to copy works in development, where the sample data is a snapshot. It fails in production at the first renumbering, because downstream systems hold a stale identifier and have no mechanism to learn it changed. The DMS workspace, the portal record, and the CRM entry all reference a number that no longer resolves.

The correct approach is synchronizing state transitions against a stable internal identifier that survives renumbering. Billing systems generally have one, and it is usually not the number people say out loud. Integrations get built against the human-readable matter number because that is the number in every conversation, and they inherit the problem at that moment.

Fiscal periods make figures time-dependent

Financial data is organized around fiscal periods, and periods close. Whether a figure is provisional or final depends on when it was requested.

A reporting integration that does not model this produces numbers that change after someone has circulated them. A report showing one figure on Tuesday and a different figure on Thursday, both correct, ends the reporting layer's credibility quickly and permanently.

What the integration has to carry:

• The period a figure belongs to, alongside the figure
• Whether that period is open or closed
• A visible indication on any output derived from an open period
• A defined behavior for retroactive adjustments posted to a closed period

Rate confidentiality is an architectural constraint

This is the requirement that most distinguishes legal billing integrations from other enterprise integration work, and it is regularly discovered late.

The integration needs matter and client data. It generally must not expose rate information. Rates are commercially sensitive in a specific way: what a firm charges one client differs from what it charges another, and the arrangements (discounts, blended rates, alternative fee structures) are confidential externally and frequently internally between practice groups.

The failure is almost never direct. Nobody builds a portal that displays a partner's hourly rate. The exposure comes through inference:

• An integration exposes matter-level billed amounts and hours for a reporting feature, and the rate is one division away
• A downstream system receives the full matter record because filtering fields looked like a refinement, and rate data now sits in a system with a different access model and audit posture
• An export intended for one practice group includes fields that permit comparison against another's arrangements

Filter at the source, not at the point of display. Retrieve only the fields the feature requires. Where a feature genuinely requires financial figures, someone has to work through what those figures allow a reader to infer. That analysis has a real duration and belongs in the estimate.

Reconcile the access models. The billing system has a mature authorization model covering practice group, matter, and role. A portal or reporting layer has its own. Where the two do not align, the integration has created a path around the firm's access controls, and reconciling them is frequently more work than moving the data.

What scoping usually omits

Three items, each cheap at design time and expensive afterward.

• The identifier decision. Whether the integration is built against a stable key or a human-facing number, and the defined behavior when matters are renumbered or merged.
• The lifecycle mechanism. How the integration learns that a matter closed, transferred, or reopened. Most estimates assume a nightly full synchronization covers it. It does not, because downstream systems have already acted on the previous state, and a full sync corrects the record without correcting the action.
• The confidentiality analysis. Which fields cross the boundary, what is inferable from them, and how the receiving system's access model compares. This requires people who understand the firm's commercial arrangements rather than its systems, which makes it slow to schedule and easy to defer.

A billing integration that accounts for these produces a larger estimate than one that does not. The cost is the same either way. The difference is whether it appears in the number that was approved or in the change orders that follow.