AI for Family Law Attorneys: Summarise Financial Disclosure Safely

Use AI to extract each bank statement into rows and sort them into a fixed category list, never to add them up. Total the rows with spreadsheet formulas and prove every month: opening balance plus credits minus debits must equal the printed closing balance. Any month that fails goes back for correction before a lawyer relies on it.

Speed is the easy part. The risk in financial disclosure is a figure that looks tidy and is wrong: a missed page, a duplicated line, a transfer between two of the client's own accounts counted as income. Every statement already prints the answer key for catching those errors, its opening and closing balances, so the checking belongs in spreadsheet formulas and never in the model's reply.

Follow me on Instagram@sagnikteaches

Why the totals check matters more than the summary

A language model is built to produce plausible text, not to be an accountant. Given forty pages of statements, it will often return a neat table. It may also skip a page, merge two similar payments, misread a 3 as an 8 on a poor scan, or produce a monthly total that is close to right and not quite. None of this announces itself. The table looks confident either way.

Connect on LinkedInSagnik Bhattacharya

The fix is to split the job by what each party does well. The AI is good at reading messy layouts and sorting descriptions such as "SQ *CAFE 4471" into a sensible category. A spreadsheet is good at arithmetic and never gets tired. The statement itself holds two numbers that act as a built-in answer key: the opening and closing balance of every period. If your extracted rows reproduce those two numbers, the extraction is almost certainly complete and correctly signed. If they do not, you know exactly which month to fix.

Subscribe on YouTube@sagnikteaches

Treat the output as a working schedule prepared for a lawyer's review, not as evidence. The responsible lawyer remains answerable for what goes onto a disclosure form, whatever tool produced the first draft. That principle shapes every step below.

Before any statement goes near a tool

Three decisions come first, and they take under an hour for the whole firm.

Choose a tool whose terms fit client financial data

Consumer chatbot accounts are the wrong place for a client's bank records. Business plans from the main vendors (ChatGPT Business, Claude Team and similar) state on their pricing pages that business content is not used for training by default; check the current wording on the vendor's own page before you rely on it, and check what retention period applies to uploaded files. Both plans start at two seats, and a standard seat lists at $20 a month billed annually or $25 billed monthly on each (as of November 2026), so a very small practice pays roughly $40 to $50 a month for the minimum. Read the details in our checklist of questions to ask before buying family law AI.

Get the client's agreement in writing

Clients are often in distress and sharing material about a spouse or partner. Add a short clause to the engagement terms saying you may use secure AI tools to organise documents, that a lawyer checks the output, and how the data is stored. If a client objects, you do the schedule by hand for that matter. Do not decide on their behalf.

Minimise what you upload

The tool does not need the full account number, the client's address or the bank's branch code to categorise transactions. Black those out first, or ask for statements as CSV, which strips most layout and identifying clutter. Name the files by matter number and month, not by the client's name. Delete uploads from the tool when the schedule is finished, and note that you did.

The worked example: twelve months into one schedule

Illustration, with invented figures. A client is disclosing finances in a divorce. She has one current account, and her statements come as twelve monthly PDFs. The goal is a categorised schedule of the year, with monthly totals the lawyer can stand behind.

Step 1: extract rows, nothing else

Upload one month at a time, not all twelve together. One month keeps each answer short enough to check and stops the model blending months. Use a prompt that forbids summarising:

You are extracting data, not analysing it.
From the attached bank statement, output a table with these columns only:
statement_month | date | description | money_out | money_in | running_balance

Rules:
- One row per transaction, in statement order, including every page.
- Copy the description exactly as printed.
- Put an amount in money_out OR money_in, never both. No negative signs.
- Do not total anything. Do not summarise. Do not skip rows.
- Before the table, state the opening balance and closing balance printed
  on the statement, and the number of transaction rows you found.
- If any text is unclear, write [UNCLEAR] in that cell instead of guessing.

Asking for the printed opening and closing balances and a row count gives you two cheap checks before you even open a spreadsheet. Paste the table into a sheet tab named for the month. After twelve months you have twelve tabs, or one long tab with a month column, whichever your team finds easier to filter.

Step 2: prove each month before categorising

Here is the check, in plain terms. For each month: opening balance, plus total money in, minus total money out, should equal the closing balance. In the sheet that is three short formulas.

Total in:   =SUMIFS(MoneyIn, Month, "2025-03")
Total out:  =SUMIFS(MoneyOut, Month, "2025-03")
Expected closing: =Opening + TotalIn - TotalOut
Difference: =ExpectedClosing - PrintedClosing   (must be 0.00)
Row count:  =COUNTIFS(Month, "2025-03")         (must equal the statement count)

Say the March statement opens at 2,418.60 and closes at 1,962.15. Your extracted rows total 3,140.00 in and 3,596.45 out. Expected closing is 2,418.60 + 3,140.00 - 3,596.45 = 1,962.15. Difference zero: March passes. April comes back 45.00 out. The totals are off by exactly 45.00, which is a strong clue: one transaction is missing or one was read as the wrong amount. Searching the PDF for 45.00 finds a gym payment the model dropped at a page break. You add the row, and April now reconciles.

Two habits make this work. First, the difference must be exactly zero, to the penny; "close enough" hides offsetting errors. Second, run the check on every month, including ones that look fine.

Step 3: categorise with a fixed list

Only after every month passes should you categorise. Give the model your category list so it does not invent new ones each run, and ask it to flag its own uncertainty:

Categorise each row using ONLY this list:
Salary and benefits | Rent or mortgage | Utilities | Groceries | Transport
Childcare and school | Insurance | Subscriptions | Dining and leisure
Medical | Loan or card payment | Transfer between own accounts
Cash withdrawal | Gifts and family | Unclear

Return: row number | category | confidence (high/medium/low) | reason in 8 words or fewer.
Do not change any amounts or descriptions. If a payee could fit two
categories, choose Unclear and say why.

Illustrative output for four rows might look like this:

The low-confidence transfer is the interesting one. A transfer to a savings account is not spending, but it is also not nothing: it points to an asset that must be disclosed. The lawyer asks the client, and the answer goes into a notes column. This is the point where a person does what the tool cannot.

Step 4: build the schedule and compare to the form

A pivot table by category and month produces the schedule. Add a column for the annual total and a column for the monthly average. Now compare the averages with what the client declared on their draft income and expenditure statement. A client who states 600 a month on groceries while the schedule shows 1,150 has either under-stated or has been paying for others; that conversation happens before the form is signed, not after the other side spots it.

The checks that catch what reconciliation misses

A month can reconcile perfectly and still hide a problem, because reconciliation only proves that the rows add up to the statement. These extra checks cover the rest.

Duplicates and double counting

If a client uploads both a monthly PDF and an annual summary, the same rows can enter twice. Add a helper column that joins date, description and amount, then flag any repeats with =COUNTIFS(Key, [@Key])>1. Genuine repeats exist (two identical coffee purchases on a day), so a flag is a prompt to look, not a deletion.

Transfers between the client's own accounts

If you analyse two accounts, a transfer out of one and in to the other appears twice, once as spending and once as income. Pair them by date and amount and tag both "Transfer between own accounts", then exclude that category from income and expenditure totals while keeping it visible. Otherwise income is overstated and the schedule invites a dispute.

Round sums and unusual patterns

Ask the spreadsheet for every item over a threshold you set (say, 1,000), every round-sum cash withdrawal and every payment to a new payee appearing in the last six months. The AI can draft a short list of questions from these for the lawyer, but the filter itself should be a formula so that nothing depends on the model's attention. The tutorial on whether AI can trace transfers explains why tracing money across accounts needs more than a summary.

Income that does not look like salary

Regular credits from a name that is not the employer, small irregular deposits, or payments from a payment app deserve a line each. Summarise them in a separate table. They often matter more than the largest items.

A second example: a business owner's mixed account

Illustration. A client runs a small business and pays some personal bills from the same account. The categorisation list above breaks down, because a payment to a supplier could be business or personal. Add two categories, "Business expense (client says)" and "Personal (client says)", and run a first pass that only sorts rows into likely business and likely personal, with every low-confidence row going to a short client questionnaire. The final split is the client's answer, recorded in the notes column, not the model's guess. This keeps the schedule honest and gives the lawyer a record of who decided each row.

A third example: a statement the model gets wrong

A realistic failure. A card statement has a "balance brought forward" line and a "payment received" credit that is really the client paying off the card from a bank account. The model lists the payment as income. The totals still reconcile against the card's printed balance, because the credit is genuinely on the statement, yet the schedule overstates income by the amount of the payment. Reconciliation did not fail; the categorisation did. The remedy is a rule in the prompt ("payments to or from a credit card in the client's name are Transfers") and a human scan of the highest-value credits every time.

What to put on file as evidence of care

If a schedule is later challenged, a good file shows how it was built. Keep a one-page record per matter containing: the tool and plan used; the date of the run; the prompt wording; the reconciliation table with the difference for each month; the names of the people who checked the months; and a list of rows corrected by hand with the reason. This takes ten minutes and replaces any later argument about whether a tool was trusted blindly.

Time and cost for a twelve-month schedule

Illustrative estimates, for a single account of moderate activity (40 to 60 transactions a month). Doing it by hand, typing from PDFs, often takes a paralegal a full day or more. With the method above, expect roughly: 15 minutes of preparation and redaction per year of statements, 20 to 30 minutes of extraction across twelve uploads, an hour of reconciliation and fixes (more if the statements are scans), 20 minutes of categorisation and an hour of lawyer review. That is about three hours of mostly checking work. Tool cost is a few dollars of a seat's monthly fee. The saving is real, but it sits in typing time; the checking time must not be squeezed, because that is the part that protects the client.

Prompts for the lawyer's review questions

Once the schedule is correct, the model can help with the next job: working out what to ask the client. Feed it the pivot summary and flagged items, not the raw statements.

Here is a categorised summary of a client's account for 12 months and a list
of flagged rows. Write a list of questions a lawyer should ask the client,
grouped by topic. Each question must refer to a specific row or total.
Do not draw conclusions about what the client is hiding. Do not give legal advice.

A fair output for our example would include: "What was the 500.00 transfer to the savings account on 14 June, and what is the balance now?" and "Rent of 1,100 stops in August; who has paid it since?" The questions are useful because each is tied to a row; a generic list of "things to ask about finances" is not.

When to do it by hand or with specialist software

Some matters are not suited to this method. Statements in a foreign currency, accounts with thousands of monthly rows, a business with its own ledgers, or a case where tracing is the main issue are better served by forensic accounting support or purpose-built document-analysis software with its own audit trail. Use the method here for the common case: one or two personal accounts, a year or two of history, and a lawyer who wants a clean first draft. Choosing between general chat tools and legal-specific products is covered in what to pay for and what to skip.

It also helps to tie the money to events. When a payment pattern changes, note the date and link it to a case chronology, so the schedule and the narrative support each other.

A fourth example: chasing the missing month

Reconciliation also tells you when a document is absent, which is easy to miss when every page you do have looks fine. Suppose a client supplies statements for January to June and August to December. The July file never arrived. The August statement opens at 1,740.25, but the June closing balance was 2,015.80. That gap of 275.55 is the net effect of a month you have not seen. Add a "bridge" check to the sheet: each month's opening balance must equal the previous month's closing balance. The formula is a single line, =Opening - PreviousClosing, and any non-zero cell means a missing statement, a page gone missing or an account switch.

The lawyer can then send a precise request instead of a vague one: "Please send the July statement for the current account; the balance moved by 275.55 between June and August." Specific requests get answered faster, and they stop a client assuming that a month with no spending can simply be left out. If a request like this needs polite wording for a stressed client, the approach in calm, consistent client emails applies directly.

The same bridge check catches a statement from the wrong account. If the opening balance of one file matches nothing in the series, it probably belongs to a different account that was filed by mistake, and discovering that before the schedule is served is far cheaper than discovering it afterwards.

A short checklist to keep beside the screen

• Client agreed in writing; business plan with no-training terms; account numbers removed.
• One month per upload; prompt forbids totals and summaries; opening, closing and row count stated.
• Every month: opening balance equals the previous closing balance; difference to the penny is zero and row counts match, or the month is fixed by hand.
• Categories from a fixed list; low-confidence rows go to the client or lawyer, not into the totals.
• Own-account transfers and card payments excluded from income and spending totals.
• Duplicate, round-sum and new-payee flags run as formulas.
• Review record saved to the file; uploads deleted from the tool; lawyer signs off.

If you would rather build this with someone alongside your team, that is the kind of job my AI implementation consultation covers: choosing the task, setting up the checks and leaving you something the team can run without me.

Questions family law teams ask about statement summaries

Can AI add up the transactions for me?

Let it read and sort the rows, but never trust its sums. Language models can miscalculate or silently drop lines. Put the extracted rows in a spreadsheet and let formulas total them, then compare each month to the statement's own opening and closing balances.

Should client statements go into a free chatbot?

No. Use a business plan or tool whose terms say your content is not used for model training, check where files are stored and for how long, and get the client's agreement in your engagement terms. Remove account numbers before upload where the tool does not need them.

What if the statement is a scanned image?

Scans raise the error rate, particularly on digits. Ask the bank for the digital PDF or a CSV export first. If you only have a scan, run the same reconciliation, and expect more months to fail the check and need hand correction.

Who signs off the finished schedule?

The responsible lawyer. The schedule is a working document built by a tool and checked by a person. Record who checked which months, so the file shows the review happened before figures went into a sworn or served document.

Further reads

• Family Law Retainer Agreements: AI Drafts, Lawyer Sign-Off — Put AI use and data handling into the engagement terms.
• Family Law Client Intake: An AI Questionnaire and Urgency Triage — Collect the financial picture at intake so statements arrive complete.
• Best AI for Family Law UK: Form E Prep and Client Updates — How the same schedule feeds a formal financial statement.
• Family Law Document Automation: Gavel Workflows or Generative AI? — Fill disclosure forms from the checked schedule.
• AI for Bankruptcy Lawyers: Intake, Schedules and Document Chasing — A sibling workflow for schedules built from client documents.
• Can Claude Read Payslips and Bank Statements for a Mortgage Case? — How another profession tests AI on payslips and statements.
• Best AI for Family Law in Australia: Privacy, Court Rules and Cost — A family law shortlist with prices, what the Family Court's AI practice direction requires, and the privacy rules that keep client data out of free tiers.
• AI for Mediators: Summaries and Agreements That Stay Neutral — A neutrality checklist for AI session notes, a balanced summary prompt, agreement drafting rules and a consent clause for every party.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: OpenAI business pricing page and Claude pricing page (seat prices, two-seat minimums, no training on business content by default), checked November 2026; general spreadsheet functions (SUMIFS, COUNTIFS).