Document processing for law firms automates check matching and payment reconciliation by extracting data from settlement and arbitration checks, then matching them against master key files using AAA numbers and claim numbers. TonaLaw uses Lido to automate this workflow with fuzzy matching (first lookup by last 8 digits of AAA number, fallback by claim number), discrepancy flagging for overpayments as small as a few cents, and duplicate claim number detection, replacing a manual process that consumed hours per batch.
Law firms that handle settlement and arbitration work process a steady flow of checks. Each check represents a payment tied to a specific case, a specific claim number, and a specific set of principal and interest amounts that should reconcile against the firm’s records. The volume is not enormous compared to, say, an accounts payable department at a Fortune 500 company. But the complexity per document is high, and the cost of errors is measured in malpractice risk rather than accounting adjustments.
The typical workflow looks like this: a check arrives (physically or as a scanned image). Someone on the team opens it, reads the AAA number or claim number printed on the check, then searches a master spreadsheet (the "key file") to find the matching case record. They compare the check amount against the expected principal and interest. If everything matches, the check gets logged and deposited. If something does not match, they need to investigate why.
That investigation is where time disappears. A discrepancy of $0.47 between the check total and the expected principal-plus-interest amount might indicate a late charge. Or an overpayment. Or a rounding difference in the interest calculation. Or an error on the payer’s side. Someone has to figure out which one it is, and that requires pulling up the case file, reviewing the payment terms, and sometimes calling the payer to confirm.
TonaLaw, a law firm that has been through 10 meetings with Lido during their evaluation and implementation process, handles exactly this workflow. (For a broader look at how AI extraction replaces manual data entry, see our guide on document automation.) Their checks come from settlement and arbitration payments. Each check needs to be matched against a master key file that updates weekly. The matching logic is not a simple lookup. It requires fuzzy matching, fallback strategies, and discrepancy analysis.
If every check printed a clean, complete AAA number that exactly matched the key file, this would be a simple VLOOKUP problem. It is not.
AAA numbers on checks are sometimes truncated. Sometimes they include prefix characters that the key file omits. Sometimes the last few digits are transposed by the payer’s system. An exact-match lookup against the full AAA number fails on a meaningful percentage of checks, which means every failed match requires manual research.
TonaLaw’s matching logic uses a two-step approach. The first lookup uses the last 8 digits of the AAA number. Truncating to the last 8 digits strips prefix variations and handles the most common formatting differences between check data and key file data. If the last-8-digits lookup returns a unique match, the check is matched and the system moves to validation.
When the first lookup fails or returns multiple matches, the system falls back to claim number matching. The claim number is a separate identifier that appears on both the check and the key file. It is an independent cross-reference. If the claim number produces a unique match, that match is used.
When both lookups fail, the check is flagged for manual review. This is the correct behavior. The system does not guess. It does not pick the "most likely" match and hope for the best. It tells the team exactly which checks could not be matched and why (no AAA match, no claim match, or multiple matches for both), so the manual effort is focused entirely on genuinely ambiguous cases.
This two-step matching logic sounds simple when described in a paragraph. Implementing it in a manual spreadsheet workflow is tedious and error-prone. The processor has to perform the truncation mentally, scan the key file, check for duplicates, try the fallback, and document the result. Doing this for a batch of 50 checks takes hours. Automating it takes seconds.
Once a check is matched to a key file record, the system compares amounts. The check total should equal the principal amount plus interest. In a perfect world, they always match. In practice, they often differ by small amounts.
A discrepancy of a few cents between the check total and the expected principal-plus-interest sum can indicate several things. It might be a late charge applied by the payer. It might be an overpayment (the payer sent more than owed). It might be a rounding difference in interest calculation, especially when interest accrues daily and the payment date shifts by a day or two from the expected date. Each of these has a different downstream action: late charges get logged, overpayments get returned or credited, rounding differences get documented.
Manual workflows handle this by eyeballing the difference. If it is small enough, the processor might just accept it without investigation. That is how overpayments go undetected and late charges go unrecorded. The amounts are individually insignificant. Collectively, over hundreds of checks per year, they add up.
Automated discrepancy flagging catches every difference, regardless of size. The system calculates the expected total from the key file (principal + interest), compares it to the extracted check amount, and flags any non-zero difference with the discrepancy amount and direction (over or under). The team reviews flagged items and decides the appropriate action. No discrepancy goes unnoticed because it was "only a few cents."
Duplicate claim numbers in a batch of checks are a red flag. They might indicate a legitimate situation (two checks for the same claim, perhaps a partial payment followed by a final payment). They might indicate an error (the same check was scanned twice). They might indicate something worse (a fraudulent duplicate submission).
In a manual workflow, duplicates are hard to catch. The processor works through checks sequentially. By the time they reach check number 43 and see a claim number that also appeared on check number 12, they are unlikely to remember or catch the duplication. Even if they are diligent about cross-checking, scanning a list of 50 previously processed claim numbers for each new check is slow and unreliable.
Automated duplicate detection is straightforward: the system maintains a running list of all claim numbers in the current batch and flags any claim number that appears more than once. The flag includes both occurrences, so the reviewer can compare the two checks side by side and determine whether the duplication is expected, accidental, or suspicious.
TonaLaw’s workflow also separates checks into two streams: TonaLaw checks and other provider checks. This separation matters for accounting and reporting purposes, and it means the duplicate detection logic needs to operate within streams (flagging duplicates within the TonaLaw batch) and optionally across streams (flagging a claim number that appears in both the TonaLaw batch and the other-provider batch).
The key file is not static. TonaLaw updates it weekly as new cases are added, existing cases are resolved, and payment expectations change. This creates a practical challenge for any automated matching system: the reference data needs to stay current.
Lido handles this through a connected lookup table that refreshes on a configurable schedule. When TonaLaw updates their key file (typically a spreadsheet in Google Sheets or Excel), the matching logic uses the current version automatically. No manual re-upload. No version confusion. No risk of matching against a stale key file that is missing the newest cases or still includes resolved ones.
This is a pattern that appears across many document processing workflows: the extraction is only as good as the reference data it validates against. A system that extracts perfectly but matches against a two-week-old key file will produce false negatives (checks that should match but do not because the case was added after the last key file update) and false positives (checks matched to cases that have since been resolved).
Check matching and validation is the core workflow, but it is not the end of the process. Once checks are matched, validated, and logged, the data often needs to flow into other systems. TonaLaw’s workflow can extend to auto-uploading processed check data to a company portal, eliminating another manual step.
The extension works because the extraction and matching pipeline produces structured, validated data. Each processed check becomes a record with fields for AAA number, claim number, check amount, matched principal, matched interest, discrepancy flag, and duplicate flag. That structured output can feed any downstream system that accepts structured input: a case management portal, an accounting system, a trust account reconciliation tool. (See how other industries handle similar multi-step extraction workflows in our post on document parsing.)
This is where document processing compounds its value. The first win is eliminating manual data entry from checks to spreadsheet. The second win is eliminating manual matching against the key file. The third win is eliminating manual data entry from the spreadsheet into downstream systems. Each step removed saves time, but more importantly, each step removed eliminates a point where human error can introduce bad data into the workflow.
Lido uses a two-step matching approach. The first lookup matches using the last 8 digits of the AAA number, which strips prefix variations and handles common formatting differences. If that fails or returns multiple matches, the system falls back to claim number matching. When both lookups fail, the check is flagged for manual review with a clear explanation of why it could not be matched.
The system compares the extracted check amount against the expected total (principal plus interest from the key file) and flags any non-zero difference. Discrepancies of a few cents may indicate late charges, overpayments, or interest calculation rounding differences. Each flag includes the discrepancy amount and direction (over or under) so the team can determine the appropriate action.
The system maintains a running list of all claim numbers in the current batch and flags any claim number that appears more than once. Both occurrences are flagged so the reviewer can compare the checks side by side. Duplicate detection operates within check streams (TonaLaw checks vs. other provider checks) and can optionally flag cross-stream duplicates.
TonaLaw updates their key file weekly. Lido connects to the key file as a lookup table and uses the current version automatically on each extraction run. No manual re-upload is needed. The matching logic always operates against the latest data, which prevents false negatives from missing new cases and false positives from matching against resolved ones.
Yes. Because the extraction and matching pipeline produces structured, validated data (AAA number, claim number, check amount, matched principal, matched interest, discrepancy flags), the output can feed any downstream system that accepts structured input. TonaLaw’s workflow can extend to auto-uploading processed records to their company portal, eliminating manual re-entry.
Extraction, matching, discrepancy flagging, and duplicate detection for a batch of 50 checks takes seconds with Lido. The same batch takes hours when processed manually because each check requires a key file lookup, amount comparison, and duplicate cross-check. The time savings compound with batch size and frequency.
%20(1).svg)
