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

At most firms, 3E, Aderant or Elite Enterprise is not primarily a financial application. It is the system of record for clients and matters, and everything financial is built on top of that. The client list is authoritative there, and so is the matter list, the responsible attorney, whether a matter is open, and which practice group and office it belongs to.

So almost any integration a firm wants — populating a portal, feeding a CRM, provisioning a DMS workspace, driving a reporting layer — ends up reading from the billing system, whether or not it was ever described as a billing integration. That centrality is where the scope comes from.

Matters have a lifecycle, and the integration has to know it

Connecting two enterprise systems normally means agreeing on entities and syncing them. Billing complicates that because its central entity isn't static.

A matter is opened, sometimes provisionally, before the client is fully onboarded. It may carry a temporary number and be renumbered after conflicts clearance. It can transfer between responsible attorneys or offices. It closes, and closed doesn't mean deleted — closed matters stay queryable and occasionally reopen. Some exist only for administrative purposes and should never reach a downstream system.

An integration that treats matters as rows to be copied works in development, where the sample data is a snapshot. It breaks in production the first time a matter is renumbered, because downstream systems hold a stale identifier with no way to know it changed. The DMS workspace, the portal record and the CRM entry all point at something that no longer exists under that number.

Handling it means syncing state transitions rather than records, against a stable internal identifier that survives renumbering. Billing systems generally have one, and it's usually not the number anyone says out loud — which is why integrations get built against the human-readable number and inherit the problem.

The second complication is time. Financial data is organized around fiscal periods, and periods close. Whether a figure is provisional or final depends on when you ask, and a reporting integration that doesn't model this produces numbers that change after someone circulated them. A report that gave one figure on Tuesday and another on Thursday, both correct, destroys trust quickly.

Rate confidentiality is a hard architectural constraint

This is what most distinguishes legal billing integrations from other enterprise work, and it's frequently discovered late.

The integration needs matter and client data. It usually 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 often internally between practice groups.

The failure is rarely direct. Nobody builds a portal displaying a partner's hourly rate. What happens is inference. An integration exposes matter-level billed amounts and hours for a reporting feature, and the rate is a division away. Or a downstream system receives the full matter record because filtering fields felt like a refinement, and rate data now sits in a system with a different access model and audit posture than the one it came from.

Building for this means filtering at the source rather than at the point of display. Pull only the fields you need, and where a feature genuinely requires financial figures, someone has to work through what those figures let a reader infer. That analysis has a real duration and belongs in the estimate.

It also means reconciling access control. The billing system has a mature model for who sees what — by practice group, matter and role. A portal or reporting layer has its own, and if the two don't line up the integration has quietly opened a path around the firm's access controls. Reconciling them is often more work than moving the data.

What scoping usually misses

The identifier problem: whether the integration is built against a stable key or a human-facing number, and what happens when matters are renumbered or merged. Cheap at design time, expensive afterward.

The lifecycle problem: how the integration learns a matter closed, transferred or reopened. Most estimates assume a nightly full sync covers it. It usually doesn't, because downstream systems already acted on the old state.

The confidentiality analysis: which fields cross the boundary, what can be inferred from them, and how the receiving system's access model compares. This needs people who understand the firm's commercial arrangements, not just its systems, which makes it slow to schedule and easy to defer.

A billing integration that accounts for these looks more expensive in the estimate than one that doesn't. It's the same cost either way. The difference is whether it appears in the number you approved or in the change orders afterward.