What Law Firms Get Wrong About Document Management Integrations

Law firm document management integrations fail on entity matching, not on connectivity. The APIs are documented and stable. The two systems have no reliable shared identifier for the things they both describe, and resolving that is the engineering work.

The integration surface is undocumented

The first finding at most firms is that no complete list exists of what connects to the document management system.

This follows from how the environments grow rather than from any failure of IT. The DMS is installed. Over the following eight years someone connects it to billing, someone adds email filing, a vendor product arrives with its own connector, a client portal is built that retrieves documents, and a reporting process begins reading the database on a schedule that was never recorded. Each decision was reasonable. Collectively they form an integration surface documented in no single place, built by people who have largely moved on.

When a firm reports that the DMS is working, the supportable claim is that nothing has visibly broken recently. Those are different statements, and the distance between them is where integration projects go wrong.

The matching problem, concretely

The assumption that does the most damage during scoping is that connecting two systems is an API problem. iManage has an API. The billing system has an API. The work is therefore wiring and authentication.

The API is the straightforward part. The systems describe the same entities with no common key.

Billing holds the canonical client and matter records: client 4471, matter 4471-0012, with a name, a responsible attorney, and a status. The DMS holds workspaces, which in principle correspond one-to-one with matters. After a decade of operation:

• Workspaces created before the matter number was issued, named after the client instead
• A matter spanning two offices with two workspaces
• A client that changed names appearing one way in billing and another in the DMS
• A large client with one workspace per practice group rather than per matter, because that is how the group preferred to work in 2016 and nobody revisited it
• Matter numbers present in a description field rather than a structured field, in an inconsistent format

Writing the join against that has no key available. The match runs on names that disagree, numbers that are sometimes present and sometimes embedded in free text, and structures that vary by office.

Estimates typically cover authentication, document retrieval, and a user interface. They rarely cover the matching logic, and they very rarely cover what the matching logic does when it is not confident.

The production failure is silence

These integrations do not fail loudly. They succeed on the roughly 85% of records that match cleanly and return nothing for the remainder.

The sequence:

1. A user opens a client record and sees no documents
2. They conclude there are none and continue
3. The integration reports no error, because from its perspective nothing failed. It searched for a match, found none, and returned an empty set, which is the specified behavior
4. Six months later someone notices that a significant client's documents have never appeared
5. The scope of the problem cannot be determined, because non-matches were never recorded

By that point the integration has been trusted for half a year, and the remediation cost is dominated by reconstruction rather than by the fix.

The design decision that prevents it

Treat unmatched records as a first-class output of the system rather than as an error condition.

The integration produces a reconciliation report with three categories:

• Matched with high confidence
• Matched ambiguously, with the candidates listed
• No match found

Someone owns that report. It shortens over time as the underlying data is corrected, which also produces the pressure to correct it. This single decision accounts for most of the difference between an integration that remains trustworthy and one that degrades without anyone noticing.

A realistic sequence

Inventory first. Before scoping anything new, establish what already touches the DMS, including scheduled jobs and vendor connectors nobody classifies as integrations. This takes longer than anyone wants and it changes the scope of everything downstream.

Profile the data before committing to a timeline. Take two hundred matters from billing and match them to workspaces manually. The resulting match rate predicts the project more accurately than any architectural discussion, and it costs one day. A 95% manual match rate and a 70% manual match rate are different projects.

Build matching with explicit confidence levels and a defined path for low confidence. Presenting a user with three possible matches is a better outcome than silently selecting one, and a substantially better outcome than silently selecting none.

Plan for the data cleanup that the reconciliation report will justify. The report converts an invisible data quality problem into a list with a length, which is what makes remediation fundable.

The integration is rarely the risk on these projects. The data underneath it is, and it is measurable before anyone commits to a number.