LawPay time entry import: get captured billable hours onto a LawPay invoice

What LawPay actually is — and isn't

It is worth being precise here, because the LawPay product line has expanded since the AffiniPay-MyCase merger and the marketing copy on the AffiniPay site no longer cleanly maps to what most working solos actually use.

LawPay Standard is the original product: a payment-rails system specialized for legal-trust-account compliance. It opens two merchant accounts at PCI-DSS-compliant processors — one for your operating account, one for your IOLTA / trust account. Credit-card processing fees come out of the operating account so they never touch trust principal (the standard interchange-plus-fee model would otherwise violate the trust-only-for-client-funds rule that has gotten plenty of solos suspended). It produces the three-way reconciliation report — bank statement vs trust ledger vs matter sub-ledger — that every state bar audits trust accounts against. It surfaces a clean Quick Bills payment page for clients to pay invoices, plus an embeddable Pay Now button for your firm site or email signature. Pricing in April 2026 is $0–$20/month base depending on your bar-association partnership (over a hundred state, local, and specialty bar associations sponsor a discount that often zeroes the monthly fee, and several large state bars include LawPay free as part of dues), plus 1.95% + $0.20 on credit-card transactions and approximately $2 flat per eCheck. It is the payment processor; it is not a billing suite.

LawPay Pro is the AffiniPay-built billing layer that includes Standard plus an invoice builder, AR aging, time tracking, and matter management. Pricing starts around $39/user/month above LawPay Standard's processing fees. It is what AffiniPay built when they wanted a Clio Manage-class competitor to live above the LawPay payment rails. Adoption is growing but most no-PMS solos who already run QuickBooks for books and a Word folder for documents have no reason to switch — Pro's invoice builder duplicates QuickBooks's, and Pro's time tracker is a manual punch-in.

The mental model that keeps the rest of this page coherent: LawPay Standard is the trust-account-and-payments layer. Anything above it — invoice templating, time tracking, matter management — is either delegated to QuickBooks-plus-ClaimHour-plus-Word (the lean stack) or bundled into LawPay Pro (the all-in-one stack). The solo's choice is which layer above LawPay to inhabit.

Where ClaimHour fits in the LawPay stack

ClaimHour sits one layer upstream of where invoices come together. The end-to-end shape:

1. Work happens. You take calls, send emails, draft documents, attend hearings.
2. ClaimHour captures it (passively, metadata-only). Call duration plus counterparty number from CallKit; email subject keywords plus send/receive counts from Apple Mail or Outlook; document edit start/stop windows from NSWorkspace plus matter-folder path matching; calendar event titles from EventKit. No audio, no email bodies, no document contents — see the metadata-only architecture deep-dive for the full refusal list.
3. You review the digest at end-of-day or end-of-week. Two minutes of clicking — approve, edit, reject, re-attribute. Each entry already has a candidate matter attached based on counterparty / path / event title.
4. Export to your billing-and-payment stack. Three pathways converge here: into QuickBooks for the operating-side ledger and invoice rendering; into LawPay Standard for the invoice builder if you don't run QuickBooks; into LawPay Pro for users on the all-in-one tier.
5. LawPay processes the payment. Trust-funded matters draw from IOLTA against the new invoice (operating account receives the funds, trust ledger reflects the draw, three-way reconciliation stays clean). Operating-billed matters charge the client card directly. The reconciliation report is generated automatically; your bar exam audit picks up nothing new.

The role each tool plays is narrow on purpose. ClaimHour does capture and only capture. LawPay does payments and trust and only those. QuickBooks (if in the stack) does books and invoices and only those. The seam between each tool is a deliberate, plain-text export schema with predictable behavior — not an opaque API integration that breaks every six months when one vendor changes a token format.

How ClaimHour exports to LawPay Standard

LawPay Standard's invoice builder accepts a CSV import for line items. ClaimHour writes that CSV directly. The schema, field-by-field:

From the ClaimHour digest, click Export → LawPay (CSV). ClaimHour writes the file to a configurable directory (default ~/ClaimHour/exports/). You log into LawPay, click New Invoice for the relevant client, click Import Line Items, select the CSV, confirm the preview, and click Save. LawPay validates the matter-reference field, line-by-line totals, and the account-destination column; you confirm; the invoice is generated and queued for client send. About forty-five seconds end-to-end for a typical week of captured time across one client.

For solos who bill multiple matters per client, ClaimHour can split a single CSV into per-matter invoices automatically — useful if your firm policy is one invoice per matter rather than one invoice per client per period. Toggle in the export dialog.

How ClaimHour exports to LawPay Pro

LawPay Pro exposes the AffiniPay developer API on its existing OAuth 2.0 surface, with time-entry create / list / update endpoints documented at the developer portal. ClaimHour pushes captured entries directly. The flow:

1. One-time setup. In ClaimHour Preferences → Integrations → LawPay Pro, click Connect. The OAuth 2.0 dance opens your browser, authenticates against your LawPay Pro account, and stores a refresh token in your macOS Keychain (never in plaintext config). The app requests scope only for time-entry create and matter-read — no payment-data scopes, no trust-account scopes.
2. Per-export workflow. Click Export → LawPay Pro from the digest. ClaimHour validates the matter-mapping (each ClaimHour matter is paired with a LawPay Pro matter ID; the first export per matter prompts you to confirm the pairing), then makes one POST per entry to the Pro time-entry endpoint. Standard rate-limit handling (exponential backoff on 429), partial-batch retry (failed entries surfaced in a re-try list at the end), and audit log written locally.
3. Pro-side review. The pushed entries land as Time Activity records in your LawPay Pro dashboard with the ClaimHour-narrative descriptions, durations, rates, and matter attribution. From there the LawPay Pro flow is the same as it would be for any time-entry source: select unbilled entries, click Bill Selected, generate the invoice, send.

The direct-API path has the obvious advantages — no manual file handling, no copy-paste — and the obvious risks — token expiry, API changes, rate limits, partial failures. ClaimHour handles all of those internally; the user-facing surface is a green check or a red retry button. We tested the integration against the LawPay Pro production API in March 2026 with a single-attorney test account; bulk testing across multi-user accounts is on the roadmap before general release of this path.

For users who do not want a direct-API integration (for any of the legitimate reasons — bar-counsel guidance against third-party API access to billing systems, IT policy at a virtual-firm host, plain risk aversion), the CSV-import path also works for LawPay Pro. The Pro tier accepts the same Standard-tier CSV schema with one additional column (matter_id, the LawPay Pro internal matter identifier) that ClaimHour fills automatically once the matter pairing is established.

Trust-funded matters: the retainer-draw workflow that keeps your bar license intact

This is the workflow that LawPay was built for and where ClaimHour earns its keep most visibly. The legal-ethics frame: client funds in trust are the client's, not yours, until you have done the work to earn them and have invoiced the client for that work. Drawing from trust before invoicing is a categorical bar violation in every US jurisdiction. Drawing from trust for work you cannot document is a Schrödinger's bar violation — fine until audited, then catastrophic.

The proper sequence:

1. Client deposits a retainer. Funds land in the trust account via LawPay (credit card or eCheck). LawPay records the deposit in the trust ledger against the client's matter.
2. You do work. ClaimHour captures the hours. The matter is tagged "retainer-against-hourly" so each captured entry knows it will draw from trust.
3. You review the digest, approve the captured entries, export to LawPay. ClaimHour writes the trust-draw line items with the account_destination=trust_draw flag.
4. LawPay generates the trust-draw invoice. The invoice itemizes each billable entry, the dollar total is computed, and on issuance LawPay debits the trust ledger and credits the operating account by the same amount. The trust ledger and the operating ledger move in lockstep. The three-way reconciliation report stays balanced.
5. The client gets a receipt. "Drawn from trust on April 25, 2026: $1,275 against your retainer balance." The client retainer balance updates; if it drops below the matter's replenishment threshold (configurable in LawPay), an automated request-for-replenishment email goes out.

The bar-audit posture this produces is exactly what you want: every trust draw has an invoice, every invoice itemizes captured time, every captured entry is a bar-recognized billable activity tied to a specific matter with a specific duration. The audit trail goes from "client paid into trust" → "lawyer captured time on matter" → "lawyer invoiced against captured time" → "trust draw matched invoice" → "operating account received funds." Each link is visible to the auditor; nothing is reconstructed from memory after the fact.

The failure mode this prevents: drawing from trust without an itemized billable basis. The most common bar grievance involving trust accounts is not theft — it is the lawyer who drew $5,000 against a retainer at month-end "for work done this month" without an itemized invoice tying that figure to specific captured time. Three years later when the client disputes, the lawyer cannot reconstruct what those hours were and the bar treats the unsubstantiated draw as conversion. ClaimHour's role here is the captured-time layer that gives the trust draw an itemized basis — every dollar drawn corresponds to a recorded entry with a duration, a matter, and a counterparty.

The full no-PMS stack: ClaimHour + QuickBooks + LawPay

Most no-PMS solos who run LawPay end up at the same three-vendor stack, and the prices have settled into a coherent picture as of April 2026:

For comparison, the bundled-PMS alternatives priced at the same April 2026 reference: Clio Complete at $159/user/month with Clio Payments bolted on for processing fees; Clio Manage Essentials at $99/user/month with Clio Payments separately; Smokeball at $49–$179/user/month depending on tier with their AutoTime included; MyCase at $39–$89/user/month with MyCase Accounting (AffiniPay-merged) on top. The cost gap to the lean stack is small in raw monthly dollars; the meaningful gap is in data residency and exit cost.

Data residency: in the lean stack, your matters live in QuickBooks (your asset, exportable to any accountant), your trust ledger lives in LawPay (the bar-blessed compliance layer), and your captured time lives in ClaimHour locally on your Mac. In the bundled stack, all three live inside one PMS tenant and are extractable only through that PMS's export tools — which historically have ranged from competent (Clio's are reasonable) to actively obstructionist (some smaller PMS vendors lock client lists behind a thirty-day waiting period on cancellation).

Exit cost: replacing one of three modular vendors is a project of hours, not weeks. Replacing the entire bundled PMS with a different one is a project that has cost six-figure firms five-figure consultant bills and quarter-long disruption. For a one-attorney shop the order of magnitude difference matters less than it does for a ten-attorney firm — but for a one-attorney shop, every billable hour spent on a billing-system migration is one not spent on a paying matter.

Why LawPay specifically — and not just "any payment processor"

This question comes up in every Reddit thread on r/Lawyertalk where a solo asks why they should pay LawPay's per-transaction rate when Stripe is cheaper or Square is bundled with their merchant account. The answer is structural and worth being precise about, because the structural answer is what makes LawPay non-substitutable for trust accounting.

Trust-account-aware processing. The single biggest reason: LawPay is one of a small number of payment processors that has architected its merchant relationships to comply with the trust-account-only-holds-client-funds rule. When a credit card is processed against a trust transaction, LawPay's processor agreement routes the interchange fee out of the operating merchant account, never out of the trust deposit. Stripe, Square, generic-merchant-account credit-card processors all deduct fees from the deposit itself by default — which means a $5,000 trust deposit lands as $4,855 in the trust account because Stripe took its fee from the gross. That is a bar-rules violation in every US jurisdiction. Solos who have tried to use Stripe for trust deposits have ended up with grievances filed against them. LawPay's whole existence as a category-defining product comes from solving this one routing problem at the processor level.

Bar-association sponsorship. Over a hundred state, county, and specialty bar associations have endorsement deals with LawPay (formally the AffiniPay-AffiniPay-Lawyers brand). The endorsement matters in two ways: it often comes with a discounted or zero monthly fee for solos who are members of the sponsoring bar; and more importantly, when something goes wrong with a payment dispute or chargeback that touches trust, the bar's existing relationship with LawPay creates a path for resolution that does not exist with a generic processor.

Three-way reconciliation as a first-class report. LawPay produces this report natively, monthly, against your bank statement / trust ledger / matter sub-ledger. QuickBooks does not. Clio's trust module does, but only inside Clio Manage. Stripe definitely does not. For a solo audited by their bar — which is when (not if) for any solo with active trust funds — having the report exportable in PDF on demand is the difference between a 30-minute audit response and a three-day reconstruction project.

Chargeback handling that knows about IOLTA. When a credit card is disputed and the original transaction was a trust deposit, the chargeback funds need to come back out of the operating account, not the trust account. LawPay handles this automatically. Other processors require you to manually move money between accounts, which is itself a bar-rules-fraught operation. LawPay specializes in the legal-trust corner case; that specialization is the whole value proposition.

The takeaway for ClaimHour users: don't try to short-circuit the trust-account layer to save the LawPay monthly fee. The fee is a few dozen dollars at most; the regulatory cost of getting trust accounting wrong is the practice. ClaimHour deliberately keeps itself upstream of any of this — we don't touch trust funds, we don't process payments, we don't produce reconciliation reports. LawPay does. Use it.

What ClaimHour doesn't replace in the LawPay stack

• The trust account itself. LawPay holds the trust account; ClaimHour writes invoice line items that draw against it. We never see, hold, or move client trust funds.
• Three-way reconciliation reporting. LawPay produces this; ClaimHour does not. If your bookkeeper or compliance attorney asks for the latest three-way report, that comes from LawPay.
• Credit-card and eCheck processing. LawPay's whole point is that it processes payments in a trust-aware way. ClaimHour does not process payments at all.
• The Pay Now button on your firm site or invoice email. LawPay generates the embedded Pay button or hosted Quick Bills link. ClaimHour generates none of the client-facing payment surface.
• Chargeback and dispute handling. LawPay handles disputes via the standard processor channels with trust-aware routing. ClaimHour has no role in dispute handling.
• The operating-account ledger. If you also run QuickBooks (recommended), QuickBooks owns the operating ledger via bank-feed reconciliation. ClaimHour exports captured time as billable line items; the dollar deposit lands in QuickBooks via the bank feed independently of ClaimHour.
• The invoice template itself. LawPay Standard renders a clean default invoice; LawPay Pro lets you customize templates; QuickBooks lets you customize further. ClaimHour exports line items; the invoice rendering happens elsewhere.

The deliberate restraint here is the same as on the QuickBooks-integration page: ClaimHour does one job well — capture billable hours that solos otherwise leak — and stays out of the regulatory liability surface that surrounds trust accounting and payment processing. Trying to do those jobs would slow down our product and put our users in the cross-hairs of compliance regimes that the existing specialist tools have already solved.

The specific failure modes ClaimHour + LawPay closes

Three failure modes that show up in the wild for solos running LawPay without an upstream capture tool, and how the ClaimHour layer addresses each:

Failure mode #1 — the trust draw without itemized basis. A solo running LawPay-only realizes at month-end that they have a $4,000 retainer balance and they think they did about $3,500 of work. They draw $3,500. Three months later the client disputes. The lawyer cannot reconstruct which specific hours were worked because they were never written down — only the aggregate gut-feel total. The bar treats this as conversion. With ClaimHour upstream, the captured-time log is the itemized basis: every dollar drawn maps to a captured entry with a duration, counterparty, and date. The dispute resolves cleanly because the basis exists.

Failure mode #2 — the operating-account underbilling. A solo running LawPay-only at the operating side ($150,000 of paid invoices last year) suspects they did more like $200,000 of billable work but cannot prove it. They priced their time off what they remembered to invoice. With ClaimHour upstream, the captured-time log is the empirical record of what was actually worked — the gap between captured-and-billed and captured-but-forgotten becomes visible. The 2026-04-25 leak post on this site walks through the math: capturing the previously-leaked hours typically adds 15–25% to a solo's annual invoiced revenue.

Failure mode #3 — the late-binding matter assignment. A solo takes a phone call from a returning client about a topic that could be one of two open matters. They make a mental note to "figure out which matter to bill it to later." Later never comes; the call goes uninvoiced. With ClaimHour upstream, the call is captured at metadata level immediately (counterparty, duration, time-of-day) and surfaces in the digest with a "needs matter assignment" flag. The two-minute end-of-day review forces the matter assignment while the context is still fresh; the entry never falls through the gap.

These are not theoretical. They are the patterns that show up repeatedly in r/Lawyertalk threads about billable-hour leakage, in Clio Legal Trends Report data on realization vs collection rates, and in the ABA's regular surveys of solo and small-firm billing practices. LawPay solves the downstream — getting the paid dollars into the right account properly. ClaimHour solves the upstream — making sure the dollars that should have been billed actually were.

How ClaimHour fits the LawPay-running solo

If you run LawPay (Standard or Pro) for trust accounting and credit-card processing, bill hourly or mixed-model, and have ever had the end-of-month realization that your invoices show fewer hours than your week actually contained — ClaimHour was built for that gap. Your trust workflow stays in LawPay. Your three-way reconciliation stays in LawPay. Your client-facing payment page stays in LawPay. The only thing that changes is that the captured-hour numbers feeding your invoices reflect the work you actually did, attributed to the right matter, routed to the right account (operating or trust draw) automatically.

Join the waitlist and we'll email when early access opens. Starter $29/mo, Pro $59/mo (the right tier for LawPay-running solos because of the bar-standard 0.1-hour rounding and the LawPay Standard CSV export schema), Scale $99/mo (two-seat, includes the LawPay Pro direct-API push for multi-user firm setups).

Get early access

Related questions

Further reading

• QuickBooks for lawyers time tracking — the books-and-invoicing companion to this page; the two pages together cover the full no-PMS stack
• Billable hour capture without a PMS subscription — the pricing deep-dive that puts LawPay + QuickBooks + ClaimHour math in context against bundled-PMS alternatives
• Time tracking without a PMS — the wedge argument for solos who have specifically refused the PMS layer
• Attorney time tracking app, lean — positioning page on what ClaimHour deliberately won't build, including the trust-accounting refusal that makes LawPay non-substitutable
• Criminal defense time tracking — the practice area most likely to combine retainer-against-hourly billing with court-appointed CJA work, both of which route through LawPay distinctly
• Family law time tracking — retainer-heavy practice area where the trust-draw discipline matters most
• Clio alternative for solo lawyers — the ClaimHour + QuickBooks + LawPay stack vs Clio Complete with Clio Payments bolted on
• Why US solo lawyers leak $30,000 a year — the leak math that the LawPay invoice-line-items capture closes
• Privilege-preserving metadata-only architecture — the technical reference for the metadata-only capture that feeds the LawPay export
• Our metadata-only privacy stance