Connecting Accounting Software to Practice Management

Almost every firm ends up running two financial systems. The practice management platform holds matters, time entries, invoices and client money. The accounting package holds the general ledger, the bank feeds, payroll, the tax filings and whatever the firm's accountant insists on seeing in a format they recognise. Both systems can produce something that looks like a balance sheet. Both can tell you what a client owes. Neither one was designed to defer to the other, and that is where the trouble starts.

The integration itself is rarely the hard part. Most practice management platforms will connect to the common small business accounting packages in an afternoon, and the vendor's setup wizard will happily start pushing invoices across before anyone has thought about what happens next. The hard part is a decision nobody schedules a meeting for, which is deciding in advance which system is authoritative for which number. Skip that decision and you do not get an integration, you get two ledgers that disagree slowly, and the disagreement usually surfaces during a reconciliation, an audit, or a partner asking why revenue looks different depending on which screen they open.

This post is about drawing that boundary properly. Which system owns what, how trust data should and specifically should not flow between them, how to reconcile the two on a cadence that catches drift while it is still small, and the double-entry problems that appear the moment both sides believe they own the same ledger. Client account rules vary substantially between US states, Canadian provinces, Australian states and England and Wales, so treat the mechanics here as general and confirm the record-keeping specifics with your own regulator before you change anything.

The failure mode starts on the day you connect the two systems

The first week after an integration goes live is usually calm. Invoices raised in practice management appear in the accounting package, the bookkeeper stops rekeying them, and everyone declares the project a success. The drift begins quietly, when someone applies a credit note in the accounting system because that is where they were sitting, or the bookkeeper adjusts a customer balance to make a bank reconciliation clear, or a payment gets recorded against a client in accounting that practice management never learns about. Each of those actions is reasonable in isolation. Together they mean the two systems now hold different versions of the same receivable.

What makes this hard to catch is that both systems keep working. Nothing errors out. The accounting package will not tell you that its accounts receivable balance no longer matches the sum of open invoices in practice management, because it has no idea that comparison is supposed to hold. Six months later a partner pulls a debtor list from one system, the accountant pulls it from the other, and the numbers are off by a few thousand with no obvious explanation. Reconstructing which of the two is correct means walking back through months of entries in both places, which is exactly the kind of work that gets deferred until it becomes a genuine problem.

What practice management is actually the source of truth for

Practice management owns everything that is matter-shaped. Time entries and their narratives, disbursements advanced on behalf of a client, the fee arrangement in force, the invoice as a legal document with its numbering and its line detail, the client trust sub-ledger, and the write-offs and write-downs that explain the gap between what was recorded and what was billed. These are not accounting artefacts. They are the firm's record of work performed against a specific engagement, and they carry evidentiary weight in a fee dispute in a way that a journal line never will.

The accounting package cannot hold that detail usefully even when it technically can. A general ledger has no concept of a responsible fee earner, a matter stage, a blended rate that changed halfway through the engagement, or a task and activity code that a corporate client's e-billing system requires. When a firm tries to force matter detail into accounting by creating a customer record per matter or a class per client, it ends up with a chart of accounts that is unmaintainable within two years and still cannot answer the questions the firm actually asks. In Casely the invoice is generated from unbilled time in one step and can be exported in LEDES 1998B where an insurer or corporate client demands it, with hourly, flat-fee, contingency and blended arrangements handled natively, because that detail belongs to the matter rather than to the ledger.

What the general ledger is actually the source of truth for

Accounting owns everything that is firm-shaped. The bank feeds and the operating account reconciliation, payroll and the associated withholdings, fixed assets and depreciation, loans and lines of credit, partner draws and capital accounts, sales tax or VAT or GST depending on where you practise, and the statutory financial statements your accountant signs. None of that is matter-specific, none of it belongs in a case file, and trying to reproduce it inside practice management is how firms end up with a second, worse accounting system that nobody trusts at year end.

The clean division is that practice management is where revenue is created and accounting is where revenue is reported. An invoice comes into existence in practice management because a lawyer did work on a matter. It arrives in accounting as a summarised journal entry that increases accounts receivable and increases fee income, mapped to whatever revenue accounts the firm's chart of accounts requires. The accounting system does not need to know which associate wrote the research memo. It needs to know that ten thousand of fee income was recognised in a given period against a given revenue account, and that a corresponding receivable exists.

Trust money is the one place a two-way sync will genuinely hurt you

If you take one thing from this post, take this. The client trust sub-ledger must live in exactly one system, that system should be practice management, and the flow to accounting must be one directional and summary only. The accounting package should carry a trust bank asset account and a matching client funds liability account, and those two should move together as a control total. It should not carry a customer-level breakdown of client money, and it should never be a place where anyone can post a trust transaction directly.

The reason is structural rather than stylistic. A general ledger is built for adjustability. Bookkeepers reclassify, they post journals to make a reconciliation clear, they backdate an entry into a closed period when the accountant asks. Every one of those habits is fine in an operating account and unacceptable in client money, because a trust ledger is a record of whose money is whose and it has to be reconstructable to the cent on any past date. Casely keeps per-matter isolated ledgers and blocks any disbursement that would exceed a matter's actual trust balance at the database transaction level rather than as a warning dialog someone can click through, and corrections are voided and remain visible rather than being deleted. A generic accounting package makes none of those guarantees, because it was never asked to.

Why the client sub-ledger cannot be reconstructed from journal entries

Firms sometimes argue that they can keep client money detail in accounting by using classes, tracking categories, or a customer record per matter, and that this saves them maintaining the same information twice. In a very small firm with a handful of active trust balances this can survive for a while. It falls apart the moment a matter has more than a few movements, or a client has more than one matter, or funds are transferred between matters, because the accounting package has no concept of a matter as an entity with a balance that must never go negative on its own.

That last point is the whole issue. A trust control account can sit comfortably in surplus while an individual client balance is negative, which means one client's money has been used to fund another client's disbursement. That is the single most serious trust failure there is, and a general ledger will not raise a flag, because from its perspective the account balances. Only a system that treats each matter as an isolated ledger with its own floor can prevent it before the money moves rather than reporting it a month later during reconciliation.

Direction of flow: detail stays home, summaries travel

Design the integration so that data moves in one direction for each type of record, and write down which direction that is. Invoices, credit notes and write-offs originate in practice management and travel to accounting as summarised journals. Client receipts against invoices are best recorded in practice management too, so that the matter's account and the client's statement stay correct, and then flow out as a receipt journal. Bank transactions, payroll, overheads and anything that never touched a matter originate in accounting and stay there.

The exception firms argue about most is payments. When a client pays by bank transfer, the payment appears in the bank feed first, which makes it tempting to record it in accounting and let it flow the other way. Resist that. The moment payments can be created in either system you have two systems that both believe they can allocate a receipt, and allocation is exactly where double counting begins. Let the bank feed tell you the money arrived, then allocate it against the invoice in practice management, and let the resulting journal be the thing accounting records. The feed becomes evidence rather than a second point of entry.

Chart of accounts mapping is most of the integration

The mapping table between practice management categories and general ledger accounts is where an integration is actually built, and it deserves more thought than it usually gets. At minimum you need a decision for fee income by practice area or by fee type if partners want revenue split that way, for recovered disbursements as distinct from fee income, for unrecovered disbursements which are a firm expense rather than a receivable, for write-offs against a contra revenue account rather than buried in a general expense line, and for the trust bank and client liability pair discussed above.

Get the disbursement treatment right on day one, because it is the mapping firms most often get wrong and the hardest to unwind later. Money advanced on a client's behalf is not fee income when it is recovered, and treating it as such inflates revenue and distorts every margin calculation the firm ever runs. Whether a given disbursement is recorded as a client-account item, a firm expense recharged, or a disbursement subject to sales tax depends on your jurisdiction and sometimes on the type of cost, so this is a question for your own accountant rather than one to settle from a vendor help article.

The double counting problem when both sides think they own the ledger

Double counting rarely announces itself. The most common version is an invoice that exists twice in accounting, once from the integration and once from a bookkeeper who raised it manually before the sync ran, usually because a client needed a copy urgently. Revenue is overstated, accounts receivable is overstated, and the client eventually pays once, which leaves a permanent open balance that somebody clears with an adjustment nobody documents. The second common version is a payment applied in accounting and then applied again in practice management, which shows the client as overpaid in one system and settled in the other.

The subtler version involves timing rather than duplication. A firm operating on an accrual basis in accounting while thinking on a cash basis in practice management will see revenue recognised in different periods depending on which system is asked, and at year end the difference gets resolved by a journal that quietly rewrites the relationship between the two. That journal is often correct as accounting, and it is still a problem, because next month the integration keeps posting on the original basis and the gap reopens. The fix is not a smarter journal. It is deciding once, in writing, what triggers revenue recognition and making sure both systems agree on that trigger.

Reconciling the two systems on a cadence that catches drift early

There are three comparisons worth running every month, and they take far less time than most firms assume once the mapping is stable. First, total accounts receivable in accounting against the sum of open invoices in practice management. Second, the trust bank and client liability control accounts in accounting against the sum of the per-matter trust ledgers, alongside the bank statement itself. Third, fee income for the period in accounting against invoiced fees in practice management, adjusted for credit notes and write-offs.

Run those three monthly and any break is small enough to trace to a specific entry within an hour. Run them annually and you are reconstructing a year of two systems from memory, which is how firms end up accepting an unexplained adjustment simply because nobody can afford to keep looking. The trust comparison in particular should never be allowed to slip, because trust reconciliation cadence is a regulated obligation in most common-law jurisdictions and the required frequency and record-keeping vary between them. Confirm what your regulator expects rather than assuming monthly is sufficient everywhere.

Who owns a correction, and how corrections travel

The rule that saves the most pain is that a correction is made in the system that owns the record, never in the system that received a copy. If an invoice was raised for the wrong amount, it is credited and reissued in practice management, and accounting receives the credit note through the same pipe that received the original. If a bank charge was posted to the wrong overhead account, it is fixed in accounting and practice management never hears about it, because overheads were never its business. Anyone who fixes a received copy has created a difference that will surface later with no audit trail explaining it.

This matters most for trust corrections, where the method is as important as the outcome. A trust error corrected by editing or deleting the original entry destroys the very thing the ledger exists to prove, which is what the balance was at every point in time. Casely voids rather than deletes, so the original entry, the void and the reason all remain visible, and each document carries a comment field recording what changed and why. When a regulator or a forensic accountant asks how a balance moved, a visible reversal is an answer and a vanished entry is a problem.

What to ask before you switch the connection on

Before enabling any integration, get concrete answers to a few questions rather than accepting a feature list. Ask which direction each record type flows and whether that direction can be changed by a user. Ask what happens when the same record is edited in both systems between syncs, because someone will eventually do that. Ask whether trust transactions can be written back from accounting under any circumstance, including bulk import. Ask what the sync does with a failed record, because a silently skipped invoice is worse than a visible error.

Then agree internally on who is allowed to touch what. In most firms the bookkeeper should have full rein in accounting and read-only visibility into practice management financials, while fee earners work in practice management and never open the accounting package at all. That division is not about trust in people, it is about making sure every number has exactly one place it can be changed. Where a firm handles matters that require restricted access, the same logic applies to information as to money, which is why ethical walls should be enforced at the data-access layer rather than hidden in a user interface, so a walled user genuinely cannot reach a restricted matter through a financial report or an exported ledger.

Decide the boundary before you connect anything

The firms that run two systems well are not the ones with the cleverest integration. They are the ones that decided, before switching anything on, that matters and client money live in practice management and that the general ledger is a reporting destination rather than a second opinion. That single decision removes most of the ambiguity that produces duplicate invoices, misallocated receipts, mismatched receivables and trust balances nobody can defend on demand. It also makes the bookkeeper's job easier, because they stop being the human reconciliation layer between two systems that were never told who was in charge.

Write the boundary down in a page. Name the owner of each record type, name the direction of flow, name the accounts each category maps to, and name the person responsible for the monthly comparisons. Review it once a year and whenever the firm adds a practice area with a different billing pattern, because a contingency practice or a fixed-fee volume practice will stress the mapping in ways an hourly practice never does. A page that anyone can read beats institutional knowledge held by one person who is on leave the week the accountant calls.

If you are drawing that boundary now, the trust side is where the decision has the most consequence, and it is worth seeing how a system that enforces per-matter balances at the database level changes what the integration has to protect against. Start with trust accounting built for law firms and how legal billing hands clean, summarised numbers to your accountant instead of asking them to untangle two ledgers at year end. The Free plan costs nothing to start, which is enough to test the boundary on a handful of live matters before you commit the whole firm to it.