Reconcile insurer payments
to remittance and receivables.
“The money arrived. What did it pay, what remains open, and are our records correct?”
A healthcare organization receives an insurer payment. An agent connects the payment with its remittance—the explanation of what the insurer paid—and the organization’s outstanding claims and balances. It gathers missing information, resolves issues and updates the records within its pre-approved authority.
The receipt is matched to the right claims and balances, permitted posting is verified, and anything unresolved is clearly identified.
A receiving-side workflow for healthcare customers. It needs bank/payment evidence, remittance information and practice-system access; it does not require control of the insurer’s outgoing payment.
Human Journey
A person in the practice’s billing or finance team turns an insurer deposit into an understood, correctly recorded payment.
“We received money from an insurer. What did it pay for, and what do we still need to collect?”
Notice the payment.
They see an insurer deposit in the bank account or a payment notification. The deposit alone may not tell them which claims it covers.
Find the explanation.
They locate the insurer’s remittance—the document or electronic record explaining the payment. It might arrive through a clearinghouse, practice system or insurer portal.
Connect the money to the explanation.
They check references and amounts to establish that this remittance belongs to this deposit. One payment can cover many claims.
Check the claims and balances.
They compare the explanation with what the practice expected to receive. Which claims were paid? Which were partially paid? What adjustments were made? What remains outstanding?
Update the practice’s records.
They apply the payment and permitted adjustments to the right accounts. Existing software may already do much of this automatically; the person reviews exceptions and verifies the result.
Chase anything that doesn’t line up.
Missing explanation? Unmatched deposit? Unexpected amount? They investigate through the bank, insurer, clearinghouse or internal records.
An unpaid claim and a missing payment are different problems. Some issues stay open for follow-up rather than being resolved in this pass.
“We know what the money settled, our records reflect it, and the remaining issues are identified.”
This job is not to make another payment.
Representative practice workflow. Tools and responsibilities vary across practices; steps may be partially automated, overlap or repeat. This serves as the human baseline for the agent journey below.
Agent Journey
An insurer receipt arrives. Follow the practice’s agent across the connected systems—from incoming evidence to verified records and open exceptions.
Proposed agent workflow for joint technical review. The following technical-alignment topics define the event source, connector contracts and exception rules to agree together.
Seven-step walkthrough
The agent acts on behalf of the practice. Rectangle supplies the connected payment and practice-facing service directly or through its software partners.
The agent works with Rectangle’s existing integrations and PayerSync capabilities. It does not replace every matching rule, repeat posting already completed, or initiate another insurer payment.
- Payment evidence → practice agent
Receive the insurer-payment event.
A new incoming insurer receipt starts the task. The agent captures the practice, source payment reference, amount and reported financial state, then checks whether this receipt already has work in progress or a completed result.
If the source reports only a pending payment or intended disbursement, retain that state and wait for the evidence needed to establish receipt. Do not label it received.
Result: one reconciliation task linked to a specific receipt, with its current evidence and status. - Agent ↔ Rectangle-connected payment, remittance and practice systems
Build the evidence bundle.
Through pre-approved access, the agent retrieves the payment details, the matching explanation of payment, the relevant claims and balances, and existing posting records.
It uses Rectangle/PayerSync and practice-system capabilities first, drawing on any additional authorized payment or remittance channels configured for the practice.
Remittance may arrive before or after the deposit. Keep the task linked to the receipt while gathering the missing side.
Result: a correlated set of source records, with missing information explicitly identified. - Agent ↔ existing matching and posting workflow
Establish what is already resolved.
The agent checks the existing workflow’s matching and posting results. It establishes which explanation belongs to the receipt and which claims and balances it covers, using the available references and domain-approved rules.
One receipt can cover many claims. The agent preserves distinctions between payments, adjustments and remaining balances instead of assuming the deposit should equal the original billed amount.
Already matched and posted? Go to verification, not another write. Supported match, not posted? Continue to the permitted update. Missing or conflicting evidence? Investigate first.
Result: each item is ready for verification, ready for a permitted update, or awaiting investigation. - Agent ↔ approved information sources and counterparties
Investigate the unresolved items.
The agent retrieves a missing explanation, requests additional payment information, checks prior postings or obtains claim details through the authorized connected systems and channels.
For example, an unexplained remaining balance may need different handling from a missing remittance or a duplicate posting. The agent gathers the evidence needed to distinguish them; it does not invent the explanation.
When new evidence resolves the gap, return to matching. If the facts remain uncertain, a dependency is unavailable or Core returns a blocked operation, keep the item open and route the required follow-up. No new human approval is inserted for routine work already covered by standing authority.
Result: an evidenced resolution or an open exception with a reason, owner/queue and next action. - Agent → approved practice-system update
Apply only the necessary updates.
For supported matches not already posted, the agent requests the permitted payment allocation and adjustments through the approved integration. It uses the evidence and current records, not a new assumption that every remaining balance should be removed.
If the update is blocked, retain that result and follow the agreed exception path. If the response is unknown or partial, inspect the existing operation before any retry. Do not submit a duplicate posting or initiate a new payment.
Result: an update reference and qualified status, or an unresolved operation requiring recovery. - Practice records → agent verification
Read back the records.
The agent retrieves the resulting postings and balances and checks them against the intended allocation. This applies both to updates it requested and to posting already completed by existing software.
An accepted request is not proof of correct records. If the payment is received but the posting is missing or incorrect, keep an accounting-repair task open; do not pay again.
Result: verified posting and remaining balances, or a specifically identified posting discrepancy. - Agent → practice / existing operations queue
Close what is complete. Keep exceptions visible.
The agent records which receipt and explanation were associated, which claims received the allocations, which updates were verified and which balances remain open.
Unresolved items retain their evidence, current status and next action. The practice can inspect the result without manually reconstructing the whole investigation.
Result: a receipt accounted for to the extent supported by verified records, with unresolved work explicitly separated from completed work.
What the practice sees afterward
- “This insurer receipt was connected to this payment explanation.”
- “These claims and balances were updated, and the postings were verified.”
- “These items remain unresolved; here is the reason and next action.”
Representative outcome states: completed postings are verified against practice records, while unresolved items remain explicitly tracked with their next action.
Shared premise & technical alignment
On behalf of a practice, an agent responds to an incoming insurer payment, uses Rectangle’s existing connected capabilities to obtain the payment explanation and practice records, coordinates unresolved reconciliation work, and verifies the resulting records—with the relevant interactions governed through DecentraCore.
Rather than starting from a blank integration landscape or recreating existing payment automation, this design builds on what Rectangle already completes automatically and focuses the agent where a person still has to investigate or coordinate.
Core design premises
- Operating model: Decentra + Rectangle. Rectangle serves healthcare practices directly and through software partners/ISVs, while Decentra provides the governed agentic execution layer. The practice is the end customer whose financial workflow is improved, and the agent acts on the practice’s behalf.
- Business trigger: an incoming insurer payment receipt. The workflow begins from an insurer payment receipt (rather than a patient payment or pre-payment notice), with the exact event source and settlement semantics confirmed per integration.
- Connection point: Rectangle’s existing integrations. Begin with the practice-system and payment capabilities already connected through Rectangle and PayerSync, scoping the agent to the specific read and write operations supported by the selected connector.
- Governance: DecentraCore. DecentraCore enforces identity, standing authority, controlled execution and evidence across each external interaction.
Platform foundation & integration scope
PayerSync & ECHO Health foundation: PayerSync’s published capabilities include automated virtual-card reimbursement processing, standardized explanations of payment (EOPs), deposit notifications and one-click PMS/EHR posting. Its published materials describe connections with ECHO Health, Optum Financial and Zelis. Together, confirm which capabilities, network connections and agent-accessible operations are available for the selected practice and connector.
Agent focus: Build around PayerSync’s established reimbursement and posting workflow so the agent focuses on unresolved evidence, cross-system coordination, exception handling and post-write verification.
Key integration details to align on: receipt-event delivery and financial status semantics (distinguishing payment notifications from confirmed bank deposits), the selected PMS/EHR connector’s read/write surface, and unattended vs. operator-assisted posting controls.
01 · Where does human investigation still happen?
Stakeholders: Practice payment-posting lead · Rectangle / PayerSync product team
Scope focus: With reimbursement processing, EOP consolidation and one-click posting already in place, align on which steps run automatically for a target practice, where an operator steps in, and which exceptions require cross-system investigation.
- Who performs reconciliation today: practice staff, an outsourced billing team, existing software or a combination?
Identify the current operator and the exact handoff point where manual reconciliation work begins.
- What does the existing Rectangle/PayerSync workflow complete automatically, and what reaches a person?
Walk through a normal receipt and an exception. Identify the concrete gap for the agent instead of recreating established automation.
- Which remaining tasks require gathering information or coordinating across systems, rather than adding another matching rule?
Use actual examples of missing explanations, inconsistent references, partial posting or unresolved balances.
02 · Which event starts our chosen journey?
Stakeholders: Rectangle integration team · Payment / bank-data owner
Trigger alignment: Confirm the delivery mechanism, receipt identifier, timing and settlement semantics for PayerSync deposit notifications or bank-feed events before selecting the primary trigger.
- Which existing connection supplies the incoming insurer receipt: Rectangle/PayerSync, a practice system, a bank feed or another connected service?
Choose the source, event or polling contract, stable receipt identifier and expected timing.
- What does that event prove: a pending transaction, funds received or another financial state?
Use the source’s actual status semantics. An insurer notification is not automatically proof of bank receipt.
- How do we recognize a receipt already handled by PayerSync, staff or another process, and accommodate remittance arriving first or later?
Define the external work-state and duplicate-detection contract without assuming all inputs arrive together.
03 · What can the existing integrations expose?
Stakeholders: Rectangle integration team · Practice-system connector owner · Clearinghouse / bank contacts
Integration surface: Confirm the agent-accessible read/write contracts across PayerSync, its payer network connections (such as ECHO Health) and the target PMS/EHR connector, including how 835 ERA data and ACH addenda references are exposed.
- Which integration will the first practice use, and what payment, explanation, claim, balance and posting data can it expose to an authorized agent?
Existing connectivity is our starting point. Together, confirm the selected connector’s supported data and read/write operations.
- Where does the matching explanation come from today—PayerSync, a clearinghouse, the practice system or an insurer channel—and how can missing records be retrieved?
Confirm format, identifiers, enrollment and supported access. Do not assume every insurer offers an API or that every connection exposes the same fields.
- Which references connect the payment, explanation and practice records? Does the bank connection expose the necessary payment references and ACH addenda?
Review an authorized sample and map identifiers. A bank statement amount alone may not establish a reliable match.
Remittance & trace context: Remittance (such as an X12 835 ERA or standardized EOP) is the explanation of payment and adjustments rather than the funds transfer itself. In ACH EFT/ERA flows, matching TRN trace numbers link the deposit to the remittance across multi-claim receipts.
04 · Where do the agent and Core meet the systems?
Stakeholders: Rectangle & Decentra integration leads
System boundary: Supported reimbursement source → PayerSync → supported PMS/EHR integration, with agent operations governed through DecentraCore.
DecentraCore governance capabilities: identity; intent and authority; funding and risk; controlled execution; evidence and disputes; enterprise and agent integration.
- For each retrieval, information request or record update, which approved integration receives the operation, and what request/result crosses the Core boundary?
Map the external participants, connector interfaces and request/response contracts across the DecentraCore boundary.
- What does the calling agent receive when an operation completes, is blocked, is pending or has an unknown result?
Define how the workflow handles each returned outcome and which operational queue receives exceptions outside standing authority.
Standing authority and policy enforcement reside in DecentraCore, while the agent and connected systems perform retrieval, reconciliation and posting verification.
05 · How do we establish correctness and verify posting?
Stakeholders: Payment-posting specialist · Rectangle / PayerSync team · Practice-system owner
Verification controls: Align on allocation rules, bank-deposit matching, post-write read-back, deduplication and recovery from uncertain writes so that every posted receipt is verified against final account balances.
- How are partial payments, combined claims, adjustments, offsets and rounding treated today? What evidence supports a correct allocation?
Keep the existing domain rules where appropriate. Equal amounts alone are not proof of a match.
- Which existing operation applies the permitted update, and what read-back proves the intended posting and resulting balances?
A successful API response is not sufficient proof of correct records. Distinguish agent-initiated updates from verification of posting already completed by existing software.
- How are concurrent staff updates, partial failures, duplicate requests and lost responses handled?
Confirm actual lookup, deduplication and retry behavior. Money received but posting failed means accounting repair—not another payment.
Keep separate: a missing receipt, a denied claim, an underpaid claim and a recovery of an earlier payment. Payment received, explanation associated and practice posting verified are also separate states.
06 · What do we need for a meaningful first proof?
Stakeholders: Practice sponsor · Rectangle operations & integration team · Privacy / security leads
Suggested pilot cohort: Start with one PayerSync reimbursement flow and one target PMS/EHR connector, covering both a standard multi-claim receipt and an exception requiring investigation.
- Can we walk through one authorized, de-identified receipt from arrival to final posting, plus one exception that needed human investigation?
Trace the bank/payment evidence, remittance explanation, claim/balance records and final posting using synthetic or appropriately de-identified pilot data.
- What is the smallest practice/integration cohort, and what access, data handling and release conditions apply?
Confirm contractual/privacy obligations, necessary data, environment and operational ownership. An existing integration does not imply unrestricted cross-system access.
- Who owns unresolved items, and what evidence closes each category?
Confirm permitted follow-up channels and queue handoff. Sending a message, receiving a promise and applying cash are different outcomes.
- What baseline measures the actual improvement?
Agree baseline definitions for unmatched receipts, unapplied cash, time to cash application, posting accuracy and manual follow-up before measuring pilot outcomes.
Architecture & discovery summary for joint technical alignment between Rectangle and Decentra.