Real Work. Real Complexity. Real Results.
Detailed accounts of complex trust accounting and check writing challenges we have solved for personal injury law firms.
Trust Accounting & Reconciliation Case Study
Rebuilding Historical IOLTA Records for Bar Reporting-Ready Review
We took up this case for reporting to the Bar.
At the beginning, it looked like a simple engagement. We had to take the trust liability ledger and prepare a reconciliation between the trust liability and the bank balance.
In simple terms, we had to arrive at three numbers:
- Trust liability
- Individual customer ledger balance
- Adjusted bank balance
- Bank balance minus uncleared checks plus uncleared deposits
On paper, it looked simple.
But when we started reviewing the records layer by layer, we found that the books were deeply disorganized and required a complete cleanup before any reliable reconciliation could be prepared.
We started analyzing the books from 2010, when the firm began maintaining records.
But there was a catch.
The client had maintained trust accounting records in multiple places. Their trust accounting books were maintained across four different QBO instances.
So the first step was to merge and consolidate the data for all years.
We finalized one QBO instance as the base QBO and started building the reconciliation from there.
Once we started reviewing the books, we noticed that the firm had not recorded deposits properly in QBO.
They were mainly recording checks issued to external parties, but the deposits were not entered in QBO as proper accounting entries.
The firm did have an offline version of deposit records, but those records were more for internal revenue tracking. They were not maintained from a proper accounting and reconciliation perspective.
This made the trust reconciliation much more difficult.
Getting deposits from 2010 onward was a very difficult task.
We decided on a cut-off date and then started matching deposits in QBO from that point onward.
During deposit matching after the cut-off date, we found that around USD 900,000 of deposits were never received in the bank, but checks had already been issued for those matters, and the matters had been archived.
This was an eye-opener for the firm as well as for us.
After that, we started reviewing the data more granularly.
Deposits had many challenges.
In some cases, one deposit was received after our cut-off date, while another related deposit was received much before our cut-off date. This generally happened in MedPay cases.
In some cases, the deposit was received during our review period, but checks had already been issued before the cut-off date.
These timing issues created complexity in the accounting and reconciliation.
Deposits in personal injury law firms are often not made client-wise.
Law firms usually collect all checks received during a specific period and deposit them together. In the bank statement, this appears as one single deposit. But that one deposit may include checks from many different cases.
For example, one bank deposit may comprise deposits from 100 different cases.
This creates a special problem in trust accounting.
Banks do not always provide detailed data beyond a specific period. So for many deposits within our cut-off period, we did not know directly which cases were included in that particular bank deposit.
To solve this, we had to use multiple sources from the client’s internal data to figure out what comprised each deposit.
We matched around 9,000 individual deposit records with around 350+ single deposit entries appearing in the bank.
The firm maintained three different IOLTA accounts across three different banks.
Each bank had a different way of reporting.
We first understood how each bank reported deposits, checks, and supporting data. Then we worked separately for each bank.
In some cases, the bank provided a bifurcation showing that one deposit entry comprised many individual checks. It also provided check copies.
We had to manually pull data from those check copies and match it with QBO.
That was difficult and time-consuming.
Another problem was that bank data did not have the case ID on the check. It only had the name.
So we had to manually check the name in the case management software and match it with the correct case.
In some cases, two people had the same name and the same settlement amount. In those situations, we had to go deeper and match using additional details such as the accident date.
It was a manual task, though we used AI wherever possible.
Since the firm had not pushed the deposit entries into QBO, we manually posted all required deposit entries so that we could reconcile them with the bank.
Once the deposit side was in better shape, we started working on the expense side - mainly the checks.
We first reconciled all checks that had cleared in the bank.
During this process, we found many challenges.
Sometimes the check number posted by the bank was wrong. In those cases, we had to go to the bank portal and check whether the check copy was available. If the check copy was available, we verified the correct check details from the check image.
Where check copies were not available, we had to identify the check based on amount, clearance date, and other available information.
In some cases, we noticed that an entire series of checks was different in QBO compared to the bank. This happened because, after printing checks, QBO data had been changed.
During the check reconciliation process, we found that some single checks had been encashed multiple times.
This amounted to a fraud issue of around USD 150,000.
We reported this to the CFO, and the firm took it up with the bank.
We also discovered cases where advance checks had been issued to clients previously, but at the time of final settlement, the lien was mistakenly not considered. This led to double compensation to the client.
We identified losses of around USD 250,000 in cases of this type.
This also included cases where duplicate checks were issued to parties and both checks were encashed because the old check had not been voided before issuing the new one.
This is how we cleaned the expense side of the trust accounting books.
Once deposits and checks were cleaned, we initially thought the base data was correct and that final reconciliation numbers would now be ready.
But that was far from true.
When we started reviewing individual customer ledgers, we noticed many negative balances.
A negative customer ledger usually means checks were issued for more than the deposit available for that matter. But in this case, the reasons were not simple. They varied from case to case.
We identified several reasons for negative balances.
1. Deposit in One IOLTA, Checks from Another IOLTA
In many cases, the deposit was received in one IOLTA account, but checks were issued from another IOLTA account.
This was very difficult to identify and reconcile.
We had to trace the deposit from one account and match it with the check issued from another account. We then reported the difference to the CFO.
The CFO transferred funds from one IOLTA account to another to correct the position.
This was a huge number - more than 300 cases, amounting to millions of dollars.
2. Checks Issued During Review Period, Deposits Before Cut-Off Date
In some cases, checks were issued during our review period, but the related deposits had been received before the cut-off date.
Because of this, the books showed negative balances.
We had to verify whether deposits had actually been received for those cases before the cut-off date and then account for them properly in QBO.
3. Replacement Checks Without Voiding Old Checks
In some cases, replacement checks were issued without voiding the old check entry.
Even though only one check was encashed in the bank, the customer ledger showed a negative balance because both check entries existed in the accounting records.
We had to manually review those cases and correct the reporting.
4. Substituted-Out Client Matters
In some matters, the client had substituted out the law firm.
Fees were never accrued from the lien deposit received.
Those cases had remained hanging for a long time and needed separate review.
The ultimate issue in the three-way reconciliation was fees.
The client we worked with transferred fees from the settlement on the date the settlement was received. These were tentative fees.
However, in QBO, we accounted for fees based on when they actually accrued to the firm.
Because of this, there was a timing difference between the bank balance and trust liability.
This timing difference had to be properly identified, documented, and considered in the three-way reconciliation.
This engagement started as a simple Bar reporting reconciliation.
But in reality, it required:
- Historical review from 2010
- Consolidation of four QBO instances
- Selection of one base QBO
- Manual deposit reconstruction
- Matching around 9,000 individual deposit records with 350+ bank deposits
- Review of three IOLTA accounts across three banks
- Understanding of different bank reporting systems
- Manual review of check copies
- Matching bank data with case management software
- Use of AI wherever possible
- Manual posting of deposit entries into QBO
- Reconciliation of cleared checks
- Review of wrong check numbers
- Review of changed QBO check data
- Identification of duplicate encashment and fraud issues
- Identification of advance-check and lien-related double compensation issues
- Review of duplicate checks and old checks not voided
- Analysis of negative customer ledger balances
- Cross-IOLTA reconciliation
- Review of substituted-out matters
- Fee timing difference analysis
- Final three-way reconciliation support
This case showed us that trust accounting for a PI law firm is not just bank reconciliation.
It is matter-wise accounting of client funds.
Settlement deposits, MedPay, checks, liens, client payouts, referring attorney payments, attorney fees, IOLTA transfers, QBO entries, bank records, and case management data all need to connect.
Only after that can trust liability, individual customer ledger, and adjusted bank balance be reconciled properly.
This is the kind of detailed backend trust accounting work PI Ledger is built for.