LawPay to Salesforce: Trust-Accounting Document Automation

If you build payment-to-CRM automations, a law firm looks familiar right up until the money lands. You have wired Stripe or PayPal into a document flow before, and the moving parts are the same. But a legal payment carries a question a normal payment never asks — is this money earned, or unearned? — and the answer decides which account it belongs in and which documents your workflow has to produce. Get that line wrong and the automation you delivered can put your client in front of a bar disciplinary committee. Your attorney client already knows the rule cold. Your job is to make sure the build encodes it.

Every step runs on a fixed rule, not a guess — the same payment, matched to the same matter, always produces the same documents.

The line your build has to respect

Unearned money — retainers, advance fees, cost deposits — belongs to the client until the work is done. It sits in a trust account, usually an IOLTA, kept strictly separate from the firm’s operating money. Earned money is the firm’s and lives in the operating account. The firm you are building for does not need this explained; what it needs is an integration that never treats one as the other.

The detail that actually shapes the build is the direction of travel. Earned fees cannot be pulled straight out of trust — they have to be transferred into operating first, tied to a specific invoice and matter, with an audit trail, and in many states the client has to be notified when it happens. That is the moment your automation earns its keep: a payment event turns into a required document, on a fixed rule, every time.

The documents your workflow has to produce

Follow one client’s money and the document set your build is responsible for falls out on its own. Each side of the earned/unearned line has its own trigger, and each trigger produces paperwork:

On the way in (unearned): the engagement letter or fee agreement sets the terms, and a trust deposit receipt acknowledges that the advance has landed in trust with the required disclosures. Two documents from one intake.

On the way out (earned): once work is performed and fees are earned, a trust-to-operating transfer authorization records the move — matter, amount, date, authorization — and a client trust statement gives the client the accounting many jurisdictions require. Two more documents from one event.

Four documents, all determined by facts the firm already captures: which matter, how much, earned or unearned, which state’s rules govern. None of it is a judgment call your automation has to make — it is a set of rules with fixed answers, which is exactly what conditional logic on the record data and a multi-document data-merge are built to handle.

Why you want deterministic output, not AI

Hand a law firm a workflow that improvises trust-accounting language and you have handed them a liability — with your name on the build. This is the case for deterministic document automation: the same inputs always produce the same documents, with the same language, every single time. No generation, no interpretation, no drift between one client’s transfer notice and the next. It is also what makes the work defensible — what the firm approves once is what every matter gets afterward.

DocupletionForms is built around exactly that one job: a single intake that conditionally selects and populates the documents a situation calls for, on fixed rule-based logic rather than AI. Plenty of platforms can merge data into a document; the reason to reach for this one on a regulated build is specialization — a predictable, repeatable output you can stand behind for a client who cannot afford surprises.

Where to draw the line: document layer, not ledger

This is the architecture decision that keeps the build clean. Do not make your automation — or DocupletionForms — the trust ledger. The earned/unearned separation happens in LawPay at processing time, and the firm’s practice-management or accounting system holds the balances and the reconciliation. That is the source of truth; leave it there.

DocupletionForms sits downstream of it. It reads the authoritative figures the accounting system already produced and turns them into the documents the workflow requires — the receipts, authorizations, and statements — driven by the firm’s own rules. The ledger stays where it belongs, and your integration stays responsible for documents, not accounting. It is the same clerical, rule-driven boundary that governs legal intake from Salesforce to completed packets — and keeping that boundary sharp is what protects both your client and your build.

The build, end to end: one intake, multiple documents, into Salesforce

Here is the whole loop as you would assemble it. A payment event on its own is just a number and a name; the value is in what your automation does next:

1. A client pays through LawPay, which separates trust from operating funds at the moment of processing.

2. The payment event — carrying its matter reference and its earned/unearned designation — lands in a staging table that holds the record until it is matched to the right matter. The merge fires on completeness, not on arrival order, so nothing generates against a half-formed record. That ordering safeguard is what keeps the workflow idempotent under real-world timing.

3. Once the record is complete, the deterministic engine selects and populates the exact documents that money-state requires — the trust receipt, or the transfer authorization and client statement — with no manual assembly.

4. The finished documents are delivered into Salesforce, attached to the matter, through the DocupletionForms Salesforce API integration and/or Zapier — multiple documents from a single submission, landing where the firm already tracks the work. The mechanics of returning completed documents to Salesforce are the same regardless of which payment feeds the loop.

The firm never leaves its system of record to get a compliant set of documents. The payment comes in through LawPay, the rules decide what has to exist, and the completed paperwork shows up on the matter in Salesforce — earned and unearned handled correctly, without anyone at the firm rebuilding the same forms by hand for the hundredth time.

For you, it is the same feeder pattern you would use on a Stripe build or a PayPal build — a payment platform in front, the deterministic document engine in the middle, and the finished packet back on the Salesforce record. LawPay simply adds the one thing a legal build cannot skip: the earned/unearned line.

Related reading: the Salesforce, Zapier & DocupletionForms data-options overview, the Stripe and PayPal payment workflows, and tools and associations for legal document professionals.