Integrating Accounting Software With Practice Management
Legal accounting integration is the connection of a firm's practice management system, where time, matters, invoices and client funds are recorded, with its accounting software, where the general ledger, tax returns and financial statements are produced. Many firms operate the two as separate islands, re-keying invoices and receipts from one into the other at month end. The result is delay, transcription errors and a client ledger that does not agree with the bank, which is precisely the kind of discrepancy that a regulator, an auditor or a reporting accountant will ask about.
Integration is not simply a technical convenience. A law firm holds two fundamentally different kinds of money: its own, earned through fees and available to meet expenses, and its clients', held on trust or in a designated client account and never available for the firm's own purposes. The accounting rules that distinguish them are stricter than in almost any other profession, and an integration that blurs the distinction, however efficiently, is worse than no integration at all. The design question is therefore not only how to move data, but which data should move, in which direction, at what level of detail and with what controls.
This article sets out a practical approach to planning, building and operating an integration between practice management and accounting software. It addresses the separation of client and office money, the mapping of matter and billing data to the general ledger, the handling of disbursements and tax, reconciliation, error handling and governance. The rules on client accounts, record keeping, audit and tax differ between jurisdictions, and practitioners must apply those of their own regulator and revenue authority. References in this article to regulations are by way of illustration only.
Why legal accounting integration is different from ordinary business integration
In an ordinary business, accounting integration is chiefly about efficiency: invoices created in one system appear in another, receipts are matched automatically and the accountant sees a current picture. In a law firm, three further considerations apply.
Client money is held in a fiduciary capacity. In most Commonwealth jurisdictions, the legal profession legislation and the regulations on accounts and records, such as the Legal Profession (Accounts and Records) Regulations in Jamaica or the equivalent accounts rules elsewhere, require separate accounts, prompt banking, regular reconciliation and a record that identifies each client's balance at all times.
The record has a regulatory audience. Accounts may be inspected by the regulator, and an accountant's certificate or report may be required periodically. The system must therefore produce records that can be understood by someone who was not involved in the transaction.
The firm has to account to the individual client. A client is entitled to know what has been received, what has been spent and what remains, matter by matter, which is a more granular requirement than the accounts of an ordinary trading company.
These features dictate a design principle which should be settled before any technical work begins: the practice management system is usually the system of record for matter-level and client-level detail, and the accounting system is the system of record for the firm's own financial position. The integration carries summarised or posted entries across the boundary, and the firm must decide precisely how.
Map the financial flows before choosing the integration
A firm should begin by documenting the money flows it needs to support, rather than starting with the features of the software. A basic inventory for most firms includes the following.
Receipt of funds from a client on account of costs, to be held in the client account until an invoice is delivered.
Receipt of funds from a client or third party for a transaction, such as a purchase price or settlement sum, held for onward payment.
Payment of disbursements to third parties on a client's behalf, from client funds or from office funds.
Delivery of an invoice for professional fees and disbursements, with any applicable sales or value added tax.
Transfer from the client account to the office account in payment of a delivered invoice.
Receipt of payment of an invoice directly into the office account.
Refund of surplus client funds at the end of a matter.
Write-offs, credit notes and adjustments.
For each flow the firm should identify which system records it first, what the corresponding entry in the other system is, who is responsible for checking it and what regulatory requirement it must satisfy. This inventory becomes the specification for the integration.
Keeping client money and office money separate
The most important rule of design is that the integration must not allow client funds to be treated as office funds in the accounting system, or the reverse. This has both technical and procedural aspects.
Separate ledgers and accounts
The client account should be represented in the accounting system as its own bank account and its own control account, clearly distinguished from the office account. The matter-level client ledger usually resides in the practice management system, while the accounting system shows the client account in total. The integration should post the total movement, with sufficient reference data to trace each posting back to the underlying matter ledger. It should not attempt to replicate every client balance as a separate account in the general ledger unless the firm's accounting method requires it.
Prevention of overdrawn client ledgers
No client ledger may ordinarily be drawn into debit. A well-designed integration enforces that no payment out of client funds can be recorded where the matter's ledger balance is insufficient, and that the check takes place in the system in which the payment is initiated. Where the accounting system will accept a payment that the practice management system would have refused, the firm has an uncontrolled route around its own safeguard, and should close it.
Transfers between client and office accounts
A transfer from client to office, in payment of fees, should only follow the delivery of an invoice or other written notification to the client, in accordance with the rules applicable in the firm's jurisdiction. The integration should therefore link each such transfer to a specific invoice number, and the authorisation workflow should be explicit. Automatic sweeping of client funds to the office account whenever an invoice is raised is generally unsafe and may breach the rules.
Mapping data between the systems
Once the flows are understood, the firm must decide what data crosses the boundary. A table of the commonly mapped items assists in planning.
Item | Originates in | Posted to accounting as | Control point |
|---|---|---|---|
Professional fee invoice | Practice management | Sales invoice or journal to fee income and receivables | Invoice number is unique and sequential across both systems |
Disbursement recharged to client | Practice management | Recoverable expense or receivable, separate from fee income | Supplier invoice is attached or referenced |
Receipt into client account | Practice management or bank feed | Increase in client bank balance and client liability | Matter and client identified at receipt |
Transfer from client to office | Practice management | Movement between client and office bank accounts, clearing the receivable | Linked to a delivered invoice |
Tax on fees and recharged items | Practice management | Output tax liability | Tax code applied consistently by item type |
Write-off or credit note | Practice management | Credit note or bad debt entry | Approved by a named partner |
The firm should also agree on the chart of accounts that will receive the postings. Practice area analysis, for example by conveyancing, litigation and corporate work, is more useful to management if it is carried into the accounting system as a tracking category or a set of income accounts than if it is left to be reconstructed later from the matter records.
Disbursements, tax and the treatment of third party costs
Disbursements are a recurring source of error. A disbursement paid on a client's behalf, such as a registry fee, court fee or counsel's fees, may be treated as a payment made as agent for the client, or as an expense of the firm that is recharged. The distinction affects how tax is accounted for and how the item appears on the invoice. The treatment depends on the tax legislation and the revenue authority's guidance in the relevant jurisdiction, and it should be settled with the firm's accountant before the integration is built, rather than discovered when the first tax return is prepared.
An illustrative worked example
The following figures are illustrative arithmetic only. They are not market data, they are not drawn from any jurisdiction, and the tax rate is assumed purely to demonstrate how entries are matched.
Suppose a client pays 5,000 into the client account on account of costs. The firm later delivers an invoice for fees of 3,000 and recharges a disbursement of 400 for a registry fee that it paid from client funds, and an assumed sales tax of 10 per cent applies to the fees but not to the disbursement. The tax is therefore 300 and the invoice total is 3,700, of which the 400 disbursement has already been settled from client funds, leaving 3,300 due from the client. The entries should appear as follows.
On receipt: client bank account debited 5,000, with a corresponding client liability of 5,000, and the matter ledger shows a balance of 5,000.
On payment of the registry fee from client funds: the client bank balance and the matter ledger fall by 400 and the fee is recorded as a disbursement incurred for the client.
On delivery of the invoice: fee income of 3,000 and tax payable of 300 are recognised, with a receivable of 3,300 from the client, the disbursement having already been settled from client funds.
On transfer from client to office, once authorised and linked to the invoice: 3,300 moves from the client bank account to the office bank account, the matter ledger falls to 1,300, and the receivable is cleared.
At the end of the sequence, the client account holds 1,300 for the client, the office account has received 3,300, and the tax liability is recorded. A reconciliation at that point should show the client bank balance equal to the total of the client ledgers, with no unexplained difference. An integration that posted the 400 as fee income, or that swept 3,700 across the boundary without regard to the disbursement already paid, would produce a visibly wrong result.
Reconciliation: the control that tests everything else
Reconciliation is the point at which the integration is proved or disproved. Firms should perform at least three comparisons, in the frequency required by their regulator.
The client bank statement balance against the client cash book balance, after allowing for items in transit.
The client cash book balance against the total of all individual client ledger balances.
The client ledger total in the practice management system against the client liability shown in the accounting system.
The third comparison is specific to integrated systems and is easily overlooked. Where the two totals disagree, the cause is almost always a posting that failed to cross the boundary, a posting that was changed in one system after transfer, or a manual entry made directly in the accounting system. The firm should keep a written record of each reconciliation, the preparer, the reviewer and the action taken on differences, so that it can be produced to the regulator or the reporting accountant.
Choosing the integration method
Integration may be achieved in several ways, and each has implications for control.
Native or built-in integration, in which the practice management platform posts directly to the accounting package, usually offers the simplest operation and the clearest audit trail, but may limit the choice of accounting software.
Middleware or connector tools can link two otherwise incompatible packages, but add a further point of failure and a further party that handles financial data.
Scheduled file exchange, by export and import of structured files, is less elegant but transparent and controllable, and is often adequate for smaller firms.
Manual entry, which remains the position of many firms, offers maximum control over each posting but the least efficiency and the highest risk of transcription error.
The right choice depends on the volume of transactions, the skill of the accounts staff and the tolerance for risk. A small firm with a modest number of matters may find that a disciplined weekly import is adequate, while a larger firm with high volumes of receipts and invoices will benefit from continuous posting.
Error handling, change control and governance
Integrations fail in ordinary ways: a connection is interrupted, a user edits an invoice after it has been posted, a tax code is changed in one system but not the other, or a bank feed duplicates a transaction. The firm should therefore decide in advance how failures will be detected and corrected.
Exception reporting
The integration should produce a daily or weekly exception report that lists postings which failed, were rejected or remain unmatched. A named person should be responsible for clearing the exceptions and the report should be retained. A silent failure that goes unnoticed for months is the most damaging kind.
Locking and amendment
Once an invoice has been posted to the accounting system, amendment should occur by credit note and reissue rather than by editing the original, so that the history is preserved. Periods that have been reconciled and reported should be locked, and the ability to unlock them should be restricted to a senior person.
Roles and segregation of duties
The person who initiates a payment from client funds should not be the person who approves it or reconciles the account. In small firms, where this is difficult, the principal should perform an independent review, and the review should be recorded.
Implementation sequence
A phased implementation reduces risk. The firm should first clean its data, reconciling the existing client ledgers and clearing stale balances before migrating anything. It should then configure the chart of accounts and tax codes, test the integration with a limited set of matters in a non-production environment, and run the old and new processes in parallel for at least one full reconciliation cycle. Only when the parallel run produces agreement should the firm cut over, and it should record the date and the opening balances in a form its accountant can verify.
Practical next steps
Document the firm's money flows and identify which system records each flow first.
Confirm with the firm's accountant the treatment of disbursements, tax and client money under the rules of the relevant jurisdiction.
Agree a chart of accounts, including practice area analysis, and a tax code table.
Decide the integration method and the direction of data flow, and confirm that no payment from client funds can bypass the matter-level balance check.
Clean and reconcile existing ledgers before migrating any data.
Run a parallel period and complete a three-way comparison before cut-over.
Appoint a person to review the exception report and a separate person to review reconciliations.
Retain written records of reconciliations, approvals and changes for the period required by the regulator.
How practice management software supports accounting integration
When time, matters, invoices, client funds and documents sit within one system, the data that must cross into the accounting package is cleaner and the audit trail shorter. Legalytech provides billing and matter management as part of a single platform for law firms, which supplies the structured records on which a reliable accounting integration depends.
This article is provided for general information only and does not constitute legal advice. Practitioners should consult the rules of their own jurisdiction and regulator.
Comments