Legal Practice Management Software: The 6 Must-Haves for Law Firms

Every practice management system has matters, documents, time entry and invoices. Put three vendors side by side and the grids agree almost entirely, which tells you nothing, because the grid records whether a capability exists and not whether it holds under pressure.

Two systems both claim an audit log. In one, an administrator can edit a past entry. In the other, the database refuses the write for every role including the vendor's own. Same row on the comparison grid. Completely different answer when a client disputes a fee.

So the useful question is not does it have X. It is what happens to X when someone is careless, or in a hurry, or acting outside their authority. A must-have is a capability whose absence eventually costs you a matter, a fee, or an argument you should have won.

Ask where a matter lives today and the honest answer is usually a list of places: a mail client, a shared drive, a spreadsheet, a wall calendar, the accounting package, and somebody's memory. Each of those works. The failure is between them, and it shows up as the same three questions nobody can answer quickly — what is the current position, what did we agree, and where is the document we actually filed.

A system earns its place by making the matter the anchor: timeline, parties, documents, deadlines, correspondence, time, expenses and billing hanging off one record. The test is simple. Open a matter you have not touched in four months. If you can reconstruct its full position in under a minute without opening anything else, the anchor is real.

A conflict check that runs after the matter is created is a record of a decision already taken. That ordering sounds pedantic until the check finds something and there is already a file, an engagement letter and two invoices.

What to require: screening at intake, against every party rather than only the client's trading name; matching that reaches organizations, directors and ultimate beneficial owners, since real conflicts usually sit one layer up; and a stored result either way. A search that found nothing is as much a record as one that found something, and the firm that cannot produce a clean search is in the same position as the firm that never ran one.

Where a conflict is waived, the reason belongs in the file, typed by the person who took the decision and stamped with their name. "We discussed it" is not a record.

Legal billing has requirements ordinary invoicing does not. Estimates and fiscal invoices must not share a numbering sequence. Tax often has to be ruled per line, because one statement can carry taxable professional time, an exempt disbursement advanced on the client's behalf, and a rebilled third-party cost that follows its own treatment. Issued documents must freeze, so that changing a firm setting next year does not silently rewrite what a client was charged.

Two questions separate systems quickly. Can you produce an unbroken sequence for each book? and if you change the firm's tax rate today, what happens to last year's invoices? If the answer to the second is anything other than "nothing", the system is not keeping a fiscal record. It is keeping a spreadsheet with a nicer interface.

Disputes surface late. The fee agreed eight months ago, the instruction someone remembers differently, the filing that went in on a particular day for a particular reason. What the firm needs at that point is not a story but a record it did not author after the fact.

Require an append-only audit trail enforced in the database rather than in application code, because code has more than one path and a database trigger has none. Require document version history, so the version that was actually sent is identifiable. Require evidence of delivery — when the client first opened the invoice, and whether they acknowledged it — since "I never received it" is otherwise unanswerable.

Most systems implement roles by hiding buttons. That is a user-interface convenience, not a boundary, and it fails the moment a request reaches the data by another route.

Ask where the rule lives. If the answer is "the app checks the role before showing the page", then the rule is a suggestion. If the answer is "the database filters every row by firm and by role, so a request for another firm's data returns nothing regardless of how it arrives", the boundary is real. For a firm holding privileged material, this is not a preference.

If your practice runs in more than one language, check the documents, not the menus. Plenty of software offers Arabic as translated labels wrapped around a left-to-right layout, and then produces an invoice in English regardless of what the client reads.

Right-to-left is a layout property applied at the document root, not a font choice. The client-facing surfaces — the invoice a client opens, the portal they log into — should render in the firm's language without anyone re-typing anything.

Mersal was built around this list rather than against a competitor's grid.

• The matter is the record. Timeline, parties, documents, deadlines, correspondence and money hang off one workspace under the firm's own numbering.
• Conflicts screen before the matter exists. Intake holds the matter until the check resolves across clients, organizations, directors, UBOs and external counsel, and the waiver reason is stamped and attributed.
• Three serial books. VAT, exempt and proforma each number independently; tax is ruled per line; issued documents freeze, so their stored values outrank current firm settings.
• The audit ledger is append-only in the database. Triggers reject UPDATE and DELETE for every role, including the service role the application itself runs as. There is no screen that edits history because the database refuses it.
• Access is filtered in the database by firm and role, not by hiding buttons.
• EN, AR and FR throughout, with true right-to-left, including the invoices and receipts you send.