Practices
Reconcile deposits to remits
Every deposit tied to its 835, and finance hears about each one that is not.
Build this with AIA brief with this use case's endpoints, events and rules, ready for your assistant to build it in your stack.
How it works
remit.matched ties an 835 to its claims and its deposit.
payment.unmatched flags a deposit or remit with no match.
Open a finance task with the payer and the amount in cents.
Review open items daily against GET /v1/remits.
Replaces Matching bank lines to remits in a spreadsheet at month end.
Built on
| Event | Sent when |
|---|---|
remit.matched | The remit matched its claims and deposit. |
payment.unmatched | A payment or deposit has no match. |
The prompt
Paste it into Claude, Codex, Cursor or ChatGPT. It links the docs pages it needs, so your assistant builds against the real API.
I'm building on the Daybook API (healthcare billing: payer calls, payer portals, 270/271 eligibility, 276/277 claim status, 835 remits, denials and appeals). Help me build this end to end.
Use case: Reconcile deposits to remits
For: Practices
Outcome: Every deposit tied to its 835, and finance hears about each one that is not.
What to build:
A reconciliation view for our finance team: a webhook handler records remit.matched against the deposit, opens a task for every payment.unmatched with the payer and amount in integer cents, and a daily job lists remits with GET /v1/remits to show what is matched, what is open and for how long.
How it works:
1. remit.matched ties an 835 to its claims and its deposit.
2. payment.unmatched flags a deposit or remit with no match.
3. Open a finance task with the payer and the amount in cents.
4. Review open items daily against GET /v1/remits.
Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/remittance.md
- https://daybookhealthcare.com/docs/api-reference/remits/list.md
- https://daybookhealthcare.com/docs/api-reference/remits/get.md
- https://daybookhealthcare.com/docs/webhooks/verifying-signatures.md
- https://daybookhealthcare.com/docs/idempotency-and-errors.md
Endpoints (base https://api.daybookhealthcare.com/v1):
- GET /remits: List remits
- GET /remits/{id}: Retrieve a remit
Webhook events: remit.matched, payment.unmatched
Ground rules:
- Authenticate with the header Authorization: Bearer <key>, the key read from DAYBOOK_API_KEY. sk_test_ keys open a sandbox and sk_live_ keys reach real payers. Never hard-code a key. Details: https://daybookhealthcare.com/docs/authentication.md
- Send an Idempotency-Key on every POST: a fresh UUID per operation, reused only to retry that operation. A key reused with a different body answers 409 idempotency_conflict.
- Verify every webhook signature before trusting the event, answer 2xx at once and do the work after.
- Keep my own ids beside Daybook's, and pass them in metadata where an endpoint takes it.
- Money is integer cents.
- Tests and fixtures use made-up data only: the sample payers bayline, keystone and meridian, NPI 1999999984, member W000000001, claim ids like clm_8Hq2Lm. Never real patient data.
- Use only the fields, endpoints and events in the docs. If something is missing, ask me rather than guess.
Ask me where finance works today (accounting system, spreadsheet or ticketing) and build the handler and daily job to feed it.Related use cases
835 to posting in your PM systemEvery 835 matched to its claims and deposit, and posted to the PM system once a person approves it.Find a missing remit in the payer portalWhen a payment shows up with no 835, Daybook signs in to the portal and brings the remit back.Recheck silent claims by phone until they moveClaims with no 276/277 answer get a payer call that repeats every few days and stops once the claim is paid.