Accounting ▸ Cross-client transfers, consents & holds

This page documents the cross-client trust transfer consent flow and the hold (earmark) it places on the source matter’s trust. It applies to the Transfer to another matter action on the Matter detail Trust accounting sub-tab and to the firm-wide Trust Operations view.

Same-client vs cross-client transfers

A matter-to-matter transfer moves trust money between two matters on the same trust account. There are two paths:

Same client on both matters — posts immediately. No consent is needed: the money never changes beneficial owner.
Different clients (the two matters have different primary clients) — the funds change whose money they are, so both clients must sign a consent document first. Nothing posts to the ledger until the consent envelope completes.
Correcting a misposting — the one exception to the rule above. See Correcting a misposting.

When you attempt a transfer between matters with different primary clients, the portal explains the requirement and offers to send the consent envelope to both clients for electronic signature.

Correcting a misposting

Two different things wear the same word. A transfer is a genuine change of hands: the money was A’s, and A agrees to give it to B. A correction of a misposting is not a change of hands at all — the money was always B’s, and only our record was wrong, because someone typed the wrong client on the way in.

A correction does not require both clients’ consent, and asking for it would be wrong. A consent form presupposes that the money is the consenting client’s to give; on a misposting it never was. Asking A to sign is asking A to release funds A never owned and never knew about — and it tells B, whose money it always was, that the firm moved their money on someone else’s say-so.

⚠️ This is not a checkbox for skipping a control. Whether a movement is a correction or a transfer is a finding of fact about whose money it was, and the person recording it is answerable for that finding. Athenty therefore requires the same evidence it requires for any other departure from a default control:

A written reason stating why the original posting was wrong. It is recorded on both matters’ ledger lines, not just one.
An authoriser. Only an Owner or Admin may record a correction, and their identity is stored on both ledger lines beside the reason.
An audit row, written at the moment the correction posts.
The same append-only discipline as every other trust entry — a correction is never edited or deleted, only reversed by a further entry.

Nothing else is relaxed. A hold is still absolute: if the funds are earmarked against another client’s pending consent, a correction cannot spend through it — at any level, Owner included. The never-negative check, the signature ceiling and the trust-account rules all apply unchanged.

If the funds really were the source client’s, even in part, this is not a correction — send the consent envelope.

Why the matter itself cannot simply be re-attributed

Once a matter has posted trust entries, GL lines or disbursements, its primary client can no longer be changed: those lines stay attached to the client they were posted under, and both ledgers are append-only, so nothing can undo them. The remedy is to open a new matter under the correct client, move any remaining balance across, and close the original.

So that the two are not left looking unrelated, Athenty links them: the original records that it is superseded by the replacement, and the replacement records that it supersedes the original. Both links are clickable from either matter, and the original keeps its own history exactly where it happened. The original matter’s earlier ID also remains searchable.

The hold (earmark) on the source matter

A consent can sit pending for days. From the moment the consent request is sent, the requested amount is held (earmarked) on the source matter’s trust:

Nothing can spend through a hold. Trust payments, disbursements, reversals and competing transfers are all checked against the available balance — the matter’s trust balance minus its active holds. The check is absolute: even an Owner/Admin using the negative-balance override cannot spend held funds. To free them, the consent must be voided (or the hold must release).
Under-funded requests are blocked up front. A consent request is refused at creation if the source matter doesn’t have the money (including money already earmarked by other pending consents) — a client is not asked to sign for funds that aren’t there.
The negative-balance override reaches a consent request. Where your organization has switched Allow negative trust balances on, an Owner or Admin may still send the request by supplying a written override reason, which is recorded against the consent and carried onto the source ledger line when the funds move. All three conditions are required — the setting on, an Owner or Admin, and a written reason — or the request is simply refused, and an organization that has not switched the setting on sees no change. The reason is recorded only when an override genuinely happened: typing one into a fully-funded request records nothing. This is the same rule the ordinary transfer, correction and requisition screens follow.
The override never reaches a hold. The two rules above sit side by side and only one of them bends: a written reason lets an authorized person accept a shortfall, and never lets anyone spend funds earmarked for another client. The funds are re-checked again at posting time, and if your organization has switched the setting off in the meantime the transfer does not post.
Holds are never perpetual. Each hold auto-releases after the org-configurable hold period (Settings ▸ Accounting ▸ Trust ▸ Cross-client consent hold period, default 30 days, 1–365). On expiry the initiator and both matters’ staff are notified. The consent itself stays open — if the clients sign later, the funds are re-checked before anything posts. Changing the setting affects new requests only; in-flight holds keep the release date set when they were placed.

A pending consent can be voided from the matter’s Trust accounting tab (Void next to the pending consent). Voiding withdraws the signing request, cancels the envelope, releases the hold, and sends notice to both clients and the matters’ staff.

Who may void:

the initiator of the consent request — a void is a retraction, not an approval, so the usual trust self-approval bar deliberately does not apply;
an Owner or Admin;
a user with the Bookkeeping Management add-on;
the Matter Responsible of the source matter (the matter the funds come from).

The same authorization model applies to voiding a trust transfer requisition.

The four dates

Every consent records its dates discretely, and the ledger is dated by the money, not the paperwork:

Date	Meaning
Held	When the consent was requested and the funds were earmarked.
Signed	When the last client signed and the envelope completed.
Moved	When the paired ledger entries actually posted — this is the ledger transaction date.
Voided	When the consent was voided/declined/canceled (if it was).

The held and signed dates never date the ledger entry — only the moved date does.

How holds appear on reports

Held funds stay inside the matter’s balance on every report — they are never deducted from a summed column or total. Instead, reports that show the affected money carry a footnote:

the originating (source) matter’s rows carry a small superscript marker (¹ ² ³ …) beside the balance;
a footnote line under the section states the held amount, the matter, the held date, and the auto-release date.

The Trust Ledger (screen, PDF and the unified export) and the Trust Bank Journals carry the footnote today; other trust surfaces are being extended.

Sources & authorities

The misposting exception is also stated with no section number, for the same reason. It was ruled on by counsel on the substance — a true correction of a misposting falls outside the cross-client consent obligation — but the paragraph reference discussed alongside it could not be confirmed against the current By-Law 9 text, so none is printed. Treat it, too, as professional-conduct practice and verify it with your regulator.
Ontario — the consent requirement is stated here with no section number, deliberately. Moving one client’s trust money to a different client’s matter changes whose money it is, so it requires both clients’ authorization — which this flow captures as a signed consent from both clients before any funds move. That obligation could not be located in the Law Society of Ontario’s By-Law 9 (Financial Transactions and Records) at source: By-Law 9 s. 18 para. 4 requires a record of transfers between clients’ trust ledgers and the purpose of each, but that is a record-keeping duty, not a consent requirement, and no By-Law 9 provision imposing consent could be confirmed. A wrong citation is worse than a missing one, so none is given — treat the consent rule as professional-conduct practice and verify it with your regulator.
The never-negative re-check at posting time follows the same By-Law 9 standard described on the trust accounting standards page (reviewed by counsel 2026-07-12 — that review does not cover this page’s consent-flow description).