The monthly close

The monthly close is where CaseFlow compares your trust account against the bank statement your bank issued, lists everything it could not account for, and produces a signed, self-contained record of the month once you have reviewed it.

It is the only place in CaseFlow where a bank balance is compared with your ledger. Two nearby pages sound similar and are not:

Page	What it is
The monthly close (this page)	You upload the bank statement. CaseFlow compares three balances, raises exceptions, and you sign the result.
Reconciliation	A live view comparing your trust ledger against the sum of your client ledgers, with a tick list for clearing transactions. No bank statement is involved.
Trust statements	A per-client PDF of one client's deposits and disbursements. A report you give a client, not a reconciliation.

Switching it on

CaseFlow switches the monthly close on for each firm itself, as part of setting up your first close. Until it has, Trust closes shows a page saying your first close is being set up and that you will get an email when it is ready. Uploading a bank statement and importing a ledger from a file wait for it too. Everything else in your trust accounts works as normal while you wait, and nothing is sent to you or your clients.

If CaseFlow ever pauses the close for your firm, you can still open every close you have and download the proof bundle for each signed one. Starting, running and signing a close wait until it is switched back on.

Before you start

You need four things:

• A trust account set up in CaseFlow (Setting up trust accounts).
• Your trust ledger for the period, in CaseFlow. Every deposit, disbursement, transfer, fee and interest posting for the month should already be recorded. If you keep it somewhere else, import it rather than retyping it.
• The bank statement for the same period, as a file. A CSV or OFX/QFX download from your bank's website is the most accurate. A PDF statement also works.
• An attorney to sign it, marked as one on their team member profile with a bar state and bar number (Marking an attorney).

The close covers one trust account for one period. If your firm holds three trust accounts, that is three closes a month.

You do not have to run your practice in CaseFlow to close a trust account

The close needs two things: a bank statement file and a trust ledger. The ledger can be CaseFlow's own, or it can be imported from whatever you keep it in now.

Step 1: Upload the bank statement

Go to Trust Accounts and click Bank statements on the account card.

Choose the file, then type four things from the statement itself:

• Period start and Period end. The period must have ended: a statement that runs to today or later is refused, so upload it once its last day has passed.
• Opening balance and Closing balance

CaseFlow reads the transaction lines out of the file and checks them against the two balances you typed: the opening balance plus every transaction must equal the closing balance, to the cent. If it does not, the statement is rejected and the reason is shown. A statement that does not add up means a line was dropped or misread, and reconciling from it would be reconciling from fiction.

Why you type the balances

CaseFlow never connects to your bank. The two balances are the check on its own reading of the file, so they have to come from you, off the statement, not out of the same file.

CSV files ask one extra question. Because every bank lays its export out differently, CaseFlow shows you the first few rows of your file and asks which column holds the date, the description, the amount and the reference. If your file has a check number column of its own as well as a reference column, map both: on a row that shows a check number, the check number is what CaseFlow matches on. Banks that split money out and money in across two columns are supported; use either the single amount column or the pair, not both. CaseFlow guesses from the column headings where it can, and you correct the guess.

PDF statements need CaseFlow Intelligence enabled for documents, because a PDF is sent to CaseFlow's AI provider, Anthropic, to read its transaction lines. A CSV or OFX file is read by CaseFlow alone and nothing is sent. If document AI is off, the upload form says so and you can turn it on in Settings or upload a CSV or OFX download instead. The same arithmetic check applies to a PDF: if the transactions read out of it do not add up to the closing balance you typed, the statement is rejected. Reading a PDF counts toward your firm's monthly CaseFlow Intelligence limit, and carries on until the limit is reached; a CSV or OFX download is never limited.

Uploading does not reconcile anything. It records the statement, ready to close against.

If you upload a new statement for a month whose close has been run but not signed, the new statement replaces the old one and CaseFlow runs the close again from it. A close cannot be signed on a statement that has been replaced.

Step 2: Reconcile the period

On the Bank statements page, an accepted statement shows a Reconcile this period button. Click it.

CaseFlow matches the bank's transactions against your ledger entries, first on amount and reference, then on amount within a few days. When the bank and your ledger show the same number of transactions of one amount under exactly the same reference, all dated this month and within a few days of each other, for example two equal court fees, it pairs them all: which goes with which changes nothing. A reference made only of digits, such as a check number, is never paired this way, because it could be one check entered twice or paid twice. Where the counts differ, an older entry carries the same reference, or another transaction could be one of them, it does not guess: it raises an exception and asks you. A disbursement is compared by the Check number on the entry (a ledger import fills it from a check number column). When the bank line and the entry of that amount carry the same check number, they are paired first. A disbursement is never paired with a bank line that names a different check: when the bank says CHECK 1022 and an entry of that amount records check 1021, the bank line and the entries of that amount stay apart and CaseFlow tells you why, naming each entry the bank line could be by its date, amount, check number and client, so you correct a mistyped number rather than record the payment twice. If another entry could also be that check, the doubt stays an exception even when the numbers agree. A bank reference made only of digits may be a check number or the bank's own transaction number, and a share draft is a credit union's check, so a different number there does not keep them apart: CaseFlow pairs them and asks you to confirm. A bank line that mentions a transfer ("TRANSFER TO OPERATING CHK 7654", "XFER FR CHK 7654") names an account, not a check, and a number with fewer than three digits once its leading zeros are dropped is not read as a check number. One more case: CaseFlow will not let you date a client's entry before that client's latest one, so a deposit you record after the client's next entry carries a later date than the bank's. Where the ledger could not have taken the bank's date, the deposit is at most a month after the bank credit, and nothing else unmatched has its amount, CaseFlow pairs the two and raises an exception asking you to confirm they are the same money. When you record a deposit late, give it the date the bank credited it if CaseFlow allows that date. If it does not, give the bank's date as the entry's Date the bank posted it (deposits and disbursements). A date given there, inside the period the statement covers, is compared with the statement as well as the date of the entry, and a pair that rests on it raises no exception: the date is your own statement, in the trust audit trail, and the matched item names both dates. A date given there that turns out wrong takes nothing away: the date of the entry is still compared, and the rule above still applies, naming the date you gave. A later date that is neither may leave the deposit unpaired.

Before any of that, an entry reversed with the Reverse entry button and its reversal cancel each other out, because neither reaches the bank: a voided cheque, or a deposit entered at the wrong amount and entered again at the right one. They are listed together under Reversed in the ledger rather than as an outstanding cheque and a deposit in transit. The exception is when the bank shows a transaction that only one of them could be: then the bank decides, as for any other entry. An entry a later close already matched to the bank is never cancelled out. And when the opening balance does not follow, a pair with an entry from before the period is listed as it stands, so the close assumes nothing about earlier months.

After matching, CaseFlow checks its work against the bank's opening balance. A reference match ignores dates, so a January bank line can point at a December entry that, by the opening balance, had already cleared in December. When the opening balance does not follow and undoing such a match makes it follow, with the bank line pairing instead with an entry of this month whose cheque number, if both show one, agrees, CaseFlow undoes it and tells you which ones it undid.

Your first close. On a first close there is no earlier signed close to say which entries were still waiting for the bank when the period opened. So where the close relies on entries from before the period clearing in it, CaseFlow lists them and asks you to confirm. Once a close is signed, the next month's close reads what it listed, and the routine case, last month's outstanding checks clearing, needs nothing from you. A skipped month breaks that chain: the close after the gap is read as a first close. A first close also names earlier entries that the bank never showed and that cancel each other exactly, such as a deposit and a check of the same amount, because the opening balance reads both as cleared and would otherwise list neither. A pair is looked for only when both entries are dated within 60 days before the period: an older one belongs to the reconciliation your firm did before CaseFlow. One entry cancelled by several is not looked for. Sign one month before you run the next: a close run before the month before it was signed is read as a first close, so CaseFlow asks you to run it again before you sign it.

It then works out three balances:

• Adjusted bank balance: the bank's closing balance, plus deposits in transit, less outstanding disbursements
• Trust ledger balance: the account's balance in CaseFlow
• Total of client ledgers: the sum of every client's individual balance in the account

When all three agree to the cent and nothing is unaccounted for, the period is reconciled.

Step 3: Read the close

Click Review the close. The page is laid out in the order you should read it.

The three balances come first, with the arithmetic shown line by line so you can follow it rather than take it on trust.

The transactions CaseFlow read come next. This is the list that came out of your file. They add up to the closing balance you typed, which proves none was dropped or misread as a whole. It does not prove each line is right: a transcription that moves an amount from one line to another still adds up. Comparing this list against the statement your bank sent you is the one step CaseFlow cannot do for you, and the attestation you sign says you did it.

The findings come last, grouped so each group answers a different question:

• Exceptions to address: everything CaseFlow could not account for
• On the statement but not in the ledger: money that moved at the bank with no matching ledger entry
• Deposits in transit: recorded in your ledger, not yet on the statement
• Outstanding disbursements: written, not yet cleared
• Reversed in the ledger: entries cancelled by their reversal, which the bank never needed to show
• Matched transactions: the ones that tied out

Exception glossary

Exception	What it means	What to do
On the statement, not in the ledger	The bank shows a transaction with nothing to match it. Bank fees and interest postings are the usual cause.	Post it to the ledger, then reconcile the period again.
More than one possible match	Two or more ledger entries could each be the transaction that cleared.	Decide which one cleared, and say so.
Outstanding for a long time	A disbursement has been outstanding well beyond the point a cheque normally clears, or a deposit recorded in the ledger has gone just as long without the bank crediting it.	For a cheque, find out whether it was ever presented: a stale cheque may need to be reissued or escheated. For a deposit, find out whether the money ever reached the trust account. If the entry is one of a deliberate correction that moved no money, such as a reversal and the entry recorded in its place for the right client, the ledger is right: say so.
A client balance is negative	One client's ledger is below zero, which means that client's matter is holding another client's money.	Correct it. This is the failure that draws discipline.
Possible duplicate ledger entry	Two ledger entries for the same client share a date, an amount and a reference.	Check whether that is two genuine payments or one entered twice. Entries carrying no reference are not compared, because two clients receiving the same amount on the same day is ordinary.
Recorded later than the bank shows	The bank credited a deposit days before the date your ledger carries for it, and the ledger could not have taken the bank's date for that client. Nothing else unmatched has its amount, so CaseFlow paired the two.	Check the bank line against the ledger deposit and client named. If they are the same money, note that. If not, the bank line is money your ledger does not show and the ledger deposit has not reached the bank: record what the bank line really is and run the close again. Next time, give a late deposit the bank's date as its Date the bank posted it when you record it, so the close can pair it without asking.
Reversed in the ledger, but the bank shows it went through	The ledger says an entry was reversed, and the bank shows the original went through: on this statement, or, for an entry from before this period, inside the opening balance. The reversal is listed as waiting for the bank. An entry an earlier close matched is not part of this close, so its reversal shows only as waiting for the bank.	If the money really moved, the reversal is wrong: record a new entry like the original, with a description explaining the correction. If the money went back, the bank has not shown it yet: check the next statement.
Paired on amount and date, not the bank reference	The bank's reference pointed a line at an entry from before this period, but the opening balance shows that entry had already cleared, so CaseFlow paired the line with an entry of this month instead. Each one is listed.	Check each pairing against the statement and the entries named. If one is wrong, say so in your explanation, correct the ledger, and run the close again.
The opening balance relies on earlier entries clearing	Entries dated before this period were matched to the bank, or cancelled by their reversal, in this period, and no signed close of the month before lists them as outstanding. The opening balance is explained only if they were still waiting for the bank when the period opened. It appears on a first close, or after a month with no signed close.	Check each entry named against your previous bank statement. If each was still outstanding when the period opened, say so. If one had already cleared, the pairing is wrong: say so in your explanation, correct the ledger, and run the close again.
Listed as outstanding last month, but the opening counts it cleared	Last month's signed close listed an entry as still waiting for the bank, nothing on this statement cleared it, and yet the bank's opening balance counts it as cleared. Both cannot be right.	Check the entry against both bank statements. An entry of the opposite amount that never reached the bank would hide it: find it, correct the ledger, and run the close again. If the two are a deliberate correction that moved no money, such as a reversal and the entry recorded in its place for the right client, the ledger is right: say so.
Earlier entries that cancel each other out	On a first close, or after a month with no signed close, two entries from before the period that the bank never showed cancel each other exactly, so the opening balance counts both as cleared. Each pair is listed.	If the pair is genuine, for example money received and paid out in full, say so. If either never reached the bank, correct the ledger and run the close again.
The bank and the ledger show different check numbers	A disbursement and a bank line of the same amount carry different check numbers. Where the bank names the check, for example CHECK 1022, CaseFlow does not pair them, and the bank line is listed as not recorded, naming the entries it could be, unless another entry pairs with it. Where the bank's number is only a reference made of digits, which may be the bank's own transaction number, CaseFlow pairs them and asks you to confirm.	If the check number in the ledger was mistyped, correct it with Edit on the entry and run the close again. If the wrong payment was recorded, reverse it and enter the right one.
The balances do not agree	The three balances differ by an amount CaseFlow cannot explain from the items above.	Work through the other exceptions first; this one usually resolves with them.
The opening balance does not follow	The statement opens at a figure your trust ledger does not reach the day before the period, and the entries still waiting to clear do not account for the difference.	Usually this means entries that cleared on an earlier statement were never ticked off as bank-cleared. Mark them reconciled and run the close again.

Step 4: Address each exception

Every exception has to be addressed before the close can be signed. Addressing one does not mean making it disappear. It means recording what you found.

For each exception, choose how it was resolved:

• Now recorded in the ledger
• A timing difference
• A bank error
• Other

and write a note saying what you found and what you did about it. A note is required. An exception with no explanation is not addressed.

Your explanation stays on the record beside the exception, in the review page and in the proof bundle. Nothing is deleted.

Running the close again replaces your explanations

If you correct the ledger and reconcile the period again, CaseFlow recalculates from scratch and the previous explanations are replaced. The button tells you how many you are about to replace, and the text of each one is written to the trust audit trail before it goes. Correct the ledger first, then explain, rather than the other way round.

Step 5: Sign

Signing records who you are, what you checked and every figure on the page, and locks the close. It cannot be undone.

The attestation is fixed wording, shown in full before you sign. It states the period and the three balances, records whether they agreed and, when they agree but the month still does not count as reconciled, how many findings stop it, says how many exceptions were raised and that each was addressed, and says that responsibility for the client funds is yours and is not delegated.

Only a team member your firm has marked as an attorney, with a bar state and bar number, can sign. Responsibility for client funds is a lawyer's under Rule 1.15, so the signature is too. Anyone else with permission can run the close and address every exception, and the review page tells them an attorney has to sign. The signature form shows the attorney the bar state and number they are signing under, and the signed record names them exactly as shown. If either is wrong, a firm administrator corrects it on their team member profile before they sign; a correction made while the form is open means reading it again before signing. CaseFlow does not check them with the bar, and a close cannot be signed while CaseFlow support is signed in to your workspace.

To sign you must:

1. Confirm that you have compared the transactions CaseFlow read against the bank statement your bank issued.
2. Type your own name, as it appears on your CaseFlow account.
3. Enter your password again.

The password is asked a second time so that signing is a deliberate act rather than a stray click. After five failed attempts, signing is locked for fifteen minutes.

This is a signature

Under the federal E-SIGN Act and state UETA, a signature is a symbol or process adopted with intent to sign. A named, authenticated person re-entering their password and typing their name against fixed wording is a signature, and the record of it is stronger than a drawn image would be. CaseFlow does not ask you to draw one.

Once signed, the close is locked. It cannot be edited or deleted, and there is no administrator override. If something later turns out to be wrong, correct it in the ledger and it appears in the next period's close, which is how a correction is supposed to look in a trust account.

That is also why an entry cannot be dated inside a month you have signed: date it after the month, and it appears in the next close. An entry dated into a month whose close has been run but not yet signed sends that close back to be run again, so you never sign a result worked out before the entry existed. CaseFlow tells you when an entry does this, and the trust audit trail records it, with any explanations the new run replaced. And an entry cannot be dated before the client's latest entry, because each entry carries the balance the client held at that point.

Step 6: The proof bundle

A signed close offers Download the proof bundle: a single ZIP that a bar examiner, an auditor or a successor firm can check without CaseFlow and without you. Also give them the date-range export described under Checking the audit trail: once its own verifier says "chain intact", it shows that the bundle is exactly the one you made, and it proves every entry end to end, including any the bundle leaves out. The cover sheet counts those as rows left out; there are some whenever another trust account or a firm-wide event, such as an export of the audit trail, has an entry between this account's own entries.

File	What it is
reconciliation_report.pdf	The close as a document: the period, the three balances, every finding, and every explanation you wrote.
attestation.json	The exact record you signed, as the bytes it was signed over.
statement_manifest.json	Every transaction read from the statement, with the period, the format, the number of transactions, and a fingerprint of the file you uploaded. The statement file itself is not copied into the bundle; it stays in your workspace.
trust_audit_log.csv	Every trust event for the account from the first day of the period through the entry that recorded your signature, in sequence, with each run of other entries in between (your other accounts' and firm-wide ones) shown as a gap. The cover sheet names that last entry's id as Through chain row.
cover_sheet.pdf	A certification of the export under Federal Rule of Evidence 902(13), carrying a line for the certifying person to sign.
hash_chain_spec.json	The specification the audit trail is sealed with, so a reader with no CaseFlow code can re-check it.
verifier.php	A small standalone script that re-checks the audit trail.
README.txt	Plain-text orientation for whoever receives the bundle.

The independent timestamp

The report carries an Independent timestamp section once the day you signed on has been sealed. Every close you sign is written to your trust audit trail, and at the end of each day that trail's seal is submitted to an independent time stamping authority, which signs it. That signature is a third party saying your signed close existed no later than that moment, which is the one thing a fingerprint cannot say on its own.

A bundle you download the same day you sign will not carry the section yet, because the day has not ended. Download it again the following day and it will. The signed certificate itself, and the manifest that names what it covers, are on the Audit checkpoints screen under Utilities.

See Daily checkpoints for the full mechanism and for how your auditor verifies the certificate without CaseFlow.

Checking the attestation

The review page prints an attestation fingerprint for a signed close. Anyone holding the bundle can confirm the signed record has not been altered, without CaseFlow and without an account:

sha256sum attestation.json

The result matches the fingerprint on the page and on the report. If the file had been edited by so much as a comma, it would not.

Checking the audit trail

Unpack the bundle into a directory and run:

php verifier.php

It recomputes every row the bundle shows in full, checks every link, including the two ends of each gap, and exits with status 0 only if all of it verifies. A failure names the row.

The bundle holds the trust events for one account across one period, which is a slice of your firm's trust trail rather than the whole of it. The verifier says so when it runs. The row immediately before the first one in the export is outside the period and is not included, so that single link is stated rather than proved.

Entries for your other trust accounts, and firm-wide events such as an export of the audit trail, sit between this account's entries in the trail. The bundle shows each run of them as a single gap: where it starts, how many entries it stands for, and the two fingerprints at its ends, and nothing else, so no other account's clients appear in it. The verifier cannot recompute a gap, so a gap could hide a change to an entry before it: the bundle on its own proves only the entries after its last gap, and the verifier's last line says how many. A bundle with no gaps says "chain intact", and then altering any row shown in full, including the first, shows up. To prove every entry end to end, give your examiner the trust audit log export with no filter other than a date range, from the first day of the close's period to the day after you downloaded the bundle: every entry in the close bundle appears there with the same id and fingerprint, and the bundle's own SHA-256 fingerprint appears on the entry that recorded its download, which shows the bundle is exactly the one you made (its README shows how to compute the fingerprint). Give the ZIP exactly as downloaded: unzipping and re-zipping it changes its fingerprint. Check that its own verifier says "chain intact".

The full trail is on the Trust audit trail screen, and the daily checkpoint covering the day you signed is the independent anchor for all of it.

What CaseFlow does not do

Stated plainly, because a trust account is the wrong place to be vague:

• CaseFlow never connects to your bank. It reads a file you uploaded. There is no bank feed and no credential for your bank anywhere in the product.
• CaseFlow holds no signature authority on your trust account and cannot move money in or out of it.
• CaseFlow does not practice law and does not give legal advice. It does not decide whether a disbursement was proper or what your jurisdiction requires.
• CaseFlow does not attest. It prepares the reconciliation; the attorney reviews it and signs it. Responsibility for client funds is not delegable, and the product is built that way on purpose.
• A signed close is not a finding of compliance. It is a record of a reconciliation performed on a date, by a named person, over a stated statement. What your bar makes of it is between you and your bar.

Who can do what

Action	Required permission
See the list of closes and read one	Trust: View
Upload a bank statement, reconcile a period, record an explanation	Trust: Edit
Sign	Trust: Edit, and marked as an attorney with a bar state and number
Mark a team member as an attorney	Firm administrator
Download the proof bundle	Firm administrator

The bundle is narrower than the rest because it contains the trust audit trail, which is deliberately not shared with non-administrator team members even when they can see the account.

Reminders

Reminders are off until CaseFlow switches them on for your firm, which it does once your first close is set up.

A trust reconciliation is a monthly obligation and the thing that stops it is almost never the reconciliation. So CaseFlow chases it, at most three times per trust account per month, at five days, twelve days and twenty days after the month ends.

Each reminder says where the close actually stopped and links to the one screen that clears it: the statement has not been uploaded, the statement is in and the close has not been run, findings are waiting for your explanation, or everything is addressed and nobody has signed. A signed close is never chased, and neither is an account your subscription does not cover, or the sample account CaseFlow creates for you to practise on, or an account opened after the month in question ended.

Reminders go to everyone who can edit trust records, which always includes administrators. Once everything is addressed and only the signature is left, the reminder goes to the attorneys among them and to administrators, who can mark one if nobody is marked yet. You can reword them or switch any of them off under Setup, Email Templates.

Availability

The monthly close is what the Trust Close plan is sold as, and it is included in the free trial so you can run a real one before you decide. It is not part of the seat plans.

Your first close is free on the trial, which runs 30 days if you signed up to run your first trust close free: one signed close, with its proof bundle, whether or not you carry on. Download the bundle before your trial ends: after that, the workspace opens only to its billing page until you subscribe.

The trust ledger, the reconciliation view and trust statements are on every plan and are unchanged by any of this.

A Trust Close subscription is billed on trust accounts, so an account you reconcile has to be one your subscription covers. You can change how many it covers on your billing page, and the way down is to deactivate a trust account you have stopped reconciling. Closes you have already signed are never affected.