Don't Let Data Drift: Integrations Governance, Ownership Matrices and Reconciliation Rules for Law-Firm Stacks

Most firms don't discover their integrations are broken until month-end. A partner asks why realization looks off, the billing coordinator pulls the WIP report, and then someone notices that 40 hours logged in the timekeeping system never made it into the accounting platform. Nobody touched anything. The sync just... drifted.

That's the frustrating part about integrations between law-firm systems. They rarely fail loudly. They fail quietly, one record at a time, until the gap is big enough to notice. By then you're not fixing a config setting — you're reconstructing three weeks of financial history from memory and email threads.

This is about integrations governance for law firms specifically: the timekeeping-to-accounting-to-DMS chain that every firm runs and almost nobody actually governs. Not a general "data hygiene" pep talk. A concrete playbook — mapping template, ownership matrix, reconciliation cadence, and the exact red-flag rules that catch drift before it becomes a write-off.

Where the drift actually starts

Before the governance stuff makes sense, it helps to be honest about how these systems fall out of sync. It's almost never a dramatic outage.

A typical example: your timekeeping tool pushes entries to accounting nightly. One associate's timekeeper ID gets changed during a name update. The integration keys on that ID. For the next eleven days, her entries silently fail to post — the sync log shows "success" because the batch ran, but her specific records fell into an error queue nobody reviews. Nine hundred dollars of billable time sits in limbo, and the first person to notice is the client's billing contact when the invoice looks light.

The pattern repeats across the stack. A matter gets opened in the practice management system but the client/matter code hasn't propagated to accounting yet, so time logged that first day has nowhere to land. A document gets filed in the DMS under a matter number that was later merged, and now it's orphaned. Trust accounting entries don't reconcile because a retainer replenishment posted to the operating ledger by mistake.

None of these are bugs in the strict sense. They're the natural result of three systems that were never designed to agree with each other, connected by integrations that assume the data on both sides is clean and stable. It rarely is.

Start with a data-source map (not a diagram)

The first governance artifact isn't a policy. It's a map of what data lives where and which system is allowed to be right when two systems disagree.

The mistake most firms make is treating every system as equally authoritative. In reality, for each critical data field, exactly one system should be the source of truth — the one everyone reconciles back to. Skip this step and every discrepancy turns into an argument about which number to trust. Those arguments always happen at month-end when nobody has time for them.

Here's a stripped-down version of what a source-of-truth map looks like for a common stack:

This diagram shows the source-of-truth flows across the common law-firm stack.

The specifics will differ by firm, but the discipline is the same: for every field that flows between systems, name one owner-system. If you can't answer "when timekeeping and accounting disagree on billed hours, which one wins?" — you don't have integrations governance, you have hope.

One thing worth flagging: trust accounting should almost always be authoritative in the accounting platform, display-only everywhere else. Firms that let practice management "manage" trust balances and then sync back to accounting create exactly the kind of two-way write path that produces IOLTA discrepancies. Keep trust one-directional.

The ownership matrix: who fixes what, and when

A source-of-truth map tells you which system is right. An ownership matrix tells you which person is responsible when the sync breaks. These are different problems, and firms constantly conflate them.

A pattern that comes up repeatedly: the integration is "owned" by whoever set it up — often an outside IT consultant or a vendor. So when a sync fails, the internal answer is "we'll open a ticket." Meanwhile the operational damage (unbilled time, misposted trust funds) is happening on the business side, where nobody feels ownership because "IT handles integrations."

1. 1
   Technical owner — the person (internal or vendor) who can actually fix the connection, credentials, and mappings.
2. 2
   Data owner — the operational person accountable for the accuracy of what flows through it. For timekeeping→accounting, this is usually the billing manager, not IT.
3. 3
   Reconciliation owner — whoever runs the periodic check confirming the two sides still match, and escalates when they don't.

The reconciliation owner is the role most firms are missing entirely. Everyone assumes "if the sync ran, we're fine." But a sync completing and a sync being correct are two different things, and only a human comparison catches the difference.

A simple version:

The trust row gets the tightest cadence and the most senior owner. That's deliberate. The cost of trust drift isn't a thin invoice — it's a bar complaint.

Reconciliation cadence: how often is enough

The right cadence depends entirely on how fast a given discrepancy turns into real damage. This is where firms over- or under-invest in pretty predictable ways.

Reconciling matter-code propagation monthly is too slow — a bad matter code corrupts every time entry logged against it in the meantime, and you're re-keying days of work. Reconciling document links daily is overkill; an orphaned document is annoying but not financially urgent, and monthly is fine.

A practical cadence framework:

1. 1
   Daily / near-real-time — trust and operating cash reconciliation. Any two-way financial write path. The blast radius here is regulatory, not just operational.
2. 2
   Weekly — timekeeping-to-billing reconciliation. Compare total hours logged in timekeeping against hours landed in accounting for the week. A weekly gap is small enough to run down while people still remember the entries.
3. 3
   On-event — matter/client code propagation. Don't wait for a calendar. When a matter opens, confirm the code reached accounting and DMS before anyone logs significant time or files documents against it.
4. 4
   Monthly — DMS-to-practice-management link integrity, timekeeper rate audits, and a full three-way tie-out (timekeeping ↔ billing ↔ collections) as part of close.

The weekly timekeeping check is the single highest-leverage habit here. Time is the rawest material a firm sells, and it's the field most prone to silent sync failure because entry volume is high and individual records are small. A missed 0.6-hour entry doesn't trip anyone's radar. Two hundred of them across a quarter is real money.

This cadence thinking connects directly to how you'd structure SLAs across a matter's life — if you've mapped your case lifecycle stages and the data each one requires, reconciliation checkpoints should line up with those stage transitions rather than floating on an arbitrary calendar.

Red-flag alerts and sample monitoring rules

Cadence catches drift on a schedule. Alerts catch it in between. The goal isn't to monitor everything — it's to monitor the handful of conditions that reliably precede a real problem.

Monitoring rules that map to the failure modes above, written so a non-technical operations person can understand what each one is watching for:

1. 1
   Volume delta alert (timekeeping→accounting)

   If total hours posted to accounting on any given night is more than roughly 10% below the hours logged in timekeeping that day, flag it. A one-day dip can be legitimate; a persistent gap is a broken mapping.

2. 2
   Error-queue non-zero alert

   If the integration's error/reject queue has any records older than 24 hours, alert the data owner. The "success" status on a batch means nothing if records are silently parking in an error bucket.

3. 3
   Orphaned-time alert

   Any time entry logged against a matter code that doesn't exist in accounting. This catches the "matter opened but code hasn't propagated" failure the same day it happens.

4. 4
   Trust variance alert

   Any difference between the trust balance in accounting and the balance displayed in practice management. This should be zero. Anything nonzero is a same-day escalation to the controller.

5. 5
   Rate mismatch alert

   A timekeeper's rate in timekeeping doesn't match the rate in accounting. Catches the case where a rate change updated one system but not the other — which quietly bills clients at the wrong number.

6. 6
   Stale-sync alert

   If any integration hasn't successfully run within its expected window (e.g., the nightly batch didn't fire), alert immediately. A sync that didn't run is worse than one that ran with errors, because there's no error queue to review.

The rule most firms overlook is the error-queue one. A surprising number of integration dashboards show green "batch completed" statuses while quietly holding failed records in a queue that no human has looked at in months. That queue is where the missing $900 of time from the earlier example was sitting the whole time.

If you're already building operational dashboards, these red-flags belong on them — though it's worth reading up on how to avoid dashboards that mislead more than they inform, because a monitoring rule that cries wolf gets ignored within a week.

Where lightweight automation earns its place

Most of the reconciliation above can be done by a person with a spreadsheet and an hour a week. For a small firm, that's often the right call — don't over-engineer.

The place where automation genuinely pulls its weight is the detection layer, not the fixing. Nobody should be manually eyeballing an error queue every morning or hand-comparing daily hour totals. That's exactly the kind of repetitive comparison that a monitoring rule inside an operational platform handles better than a human — it runs every night without fatigue and only pulls someone in when a threshold actually trips. The human stays in charge of judgment (why did trust drift? whose rate is wrong?); the system handles the tireless watching.

The distinction that matters: automate the watching, keep humans on the deciding. Firms that try to auto-fix discrepancies — auto-re-posting failed entries, auto-merging codes — tend to turn a small drift into a bigger, harder-to-trace mess. A failed trust entry should stop and wait for the controller, not quietly retry.

A real scenario

A ten-attorney litigation firm ran timekeeping and accounting as separate systems connected by a nightly sync set up years earlier by a consultant nobody could still reach. No reconciliation owner, no error-queue review — the classic setup.

Over roughly a quarter, a mix of failed entries (a couple of timekeeper ID changes, one merged matter code) meant somewhere around 60–70 billable hours never made it to invoices. At their blended rate, that's in the neighborhood of $18k–$22k that simply never got billed, discovered only because a client questioned a thin invoice.

The fix wasn't a new system. It was three changes: a named reconciliation owner (the billing coordinator, an hour every Friday), a weekly hours-delta comparison, and a standing alert on the error queue. Within two months the queue was being cleared same-week, and the recurring "where did these hours go" surprises at close basically stopped. Not a dramatic transformation — just a leak that stopped leaking.

When this level of governance is overkill

Honestly, not every firm needs the full matrix.

1. 1
   A true solo with everything in one all-in-one platform and no cross-system syncs doesn't have integration drift to govern — there's only one system. Adding a reconciliation cadence there is ceremony, not control.
2. 2
   Firms mid-migration shouldn't build permanent reconciliation rules against systems they're about to retire. Do temporary manual checks during the transition, then formalize once the target stack is stable.

Where this playbook clearly earns its keep is the messy middle: multiple specialized systems (separate DMS, separate accounting, separate timekeeping), multiple people entering data, and enough matter volume that a silent gap can grow for weeks before anyone notices. That's most firms somewhere between five and fifty attorneys.

The one habit that matters most

If you take nothing else from this: assign a reconciliation owner and give them a weekly timekeeping-to-billing tie-out. That single practice catches the majority of drift that actually costs firms money, and it doesn't require new software, a consultant, or a governance committee.

“

Put the weekly tie-out on the reconciliation owner's calendar as a recurring meeting so it becomes non-optional.

Everything else here — the source-of-truth map, the ownership matrix, the alert rules — makes that habit sturdier and harder to skip. But the habit is the core. Integration drift isn't a technology failure so much as an accountability gap. Once someone's name is on "confirm these two systems still agree," the gap closes on its own.

Green sync statuses lie. Someone has to check the numbers behind them — on a schedule, with authority to escalate. Do that, and the month-end surprises quietly go away.