At a glance
- Reconciliation runs in four stages: remittance ingestion, expected-payment matching per client, exception flagging, and review.
- Matching runs inside one client's ledger at a time. A payment that could belong to two clients is assigned by a person, never by the software.
- Rules match the clear cases. The software groups and explains the rest, and a person decides every exception.
- A 360 AI Blueprint ranks this workflow against other RCM work using your own volumes and data, not a generic order.
- Start by replaying past ERAs from one payer through two or three client accounts, and compare the results before anything posts.
How do you reconcile payer remittances across multiple client accounts?
Multi-client AP reconciliation is the routine of proving that every payment a payer sent matches what a specific client account expected, and that every difference has an owner. You ingest each remittance, match it to that client's expected payments, and put what does not tie out in front of a person. Here, "AP reconciliation" means reconciling payer remittances, the money coming in for each client account. A billing company's own accounts payable is out of scope.
The raw material is the electronic remittance advice, or ERA: the payer's electronic explanation of its payment. Its counterpart is the expected payment: what a client account should receive for a claim, taken from your own records. One clearinghouse, Stedi, says in its guide that "Providers primarily use ERAs for payment reconciliation" [1]. It also says "An ERA is tied to a payment, not a particular claim." It adds that "A single claim can appear across multiple ERAs – for example, if the claim is paid in installments." [1]
The multi-client ERA reconciliation workflow
In medical billing, payment posting automation has to match at the payment level and the claim level, inside the client the money belongs to. The table shows where a person takes over.
| Stage | What the software does | Inputs it needs | Human checkpoint |
|---|---|---|---|
| 1. Remittance ingestion | Pulls ERA files and payment-advice PDFs from each route into one standard record: client, payer, trace number, payment date, claim references, amounts, reason codes. Duplicates are set aside. | Each client's remittance route, a field map per route, and payer enrollment in place. | A file with no check or EFT trace number is listed for a person to resolve. The software does not patch it. |
| 2. Expected-payment matching per client | Links each payment to its bank deposit, then each claim line to that client's expected payment. Exact matches are resolved by rule. Near matches are proposed with the reason. | Per-client expected payments, deposit data, and a written tolerance rule. | A posting specialist approves every near match before it posts. The tolerance rule has a named owner. |
| 3. Exception flagging | Labels each item that fails to match with an exception type (see the routing table), attaches the evidence and groups items with the same likely cause. | The exception types, plus each client's recorded fee terms. | The reviewer owns the label. If the type is unclear, the item waits unlabeled in a shared queue. |
| 4. Review and posting | Shows each item beside its remittance and expected payment with a proposed action. After approval, it prepares the posting and logs the decision. | A reviewer per client, plus the approval rule for adjustments and write-offs. | The billing or finance team approves, edits or rejects every posting, adjustment and write-off. The rule owner reviews closed items to update the rules. |
What does an agent automate in payment posting?
In payment posting, an agent (software that runs these steps and hands the result to a person) automates the preparation, not the decision. It reads the remittance, finds the matching expected payment, drafts the posting entry with the evidence attached, and queues anything that does not tie out. The posting specialist approves before the entry is written to the client's account.
- Parsing: read ERA data and PDFs into the same fields for every client.
- Matching: pair payments, deposits and claim lines by reference and amount, inside one client at a time.
- Drafting: prepare the posting entry or the adjustment, with the remittance line and the expected payment shown beside it.
- Grouping and logging: collect items with the same likely cause for one reviewer, and record each approval.
One practical dependency sits outside the software. The same vendor's documentation states that "Processing ERAs always requires transaction enrollment with the payer." [2] Settle whether each client's payers are enrolled before matching work starts.
Who reviews an unusual or partial payment?
A person on the billing or finance team reviews every unusual or partial payment, and we recommend assigning a named reviewer per client account. The software flags and explains the item. The reviewer decides whether to post, adjust, hold or go back to the payer, as the organization's own operating choice.
| Exception type | What flags it | Who reviews | Typical next step |
|---|---|---|---|
| Partial or short payment | Paid amount is below the expected payment beyond the written tolerance. | Posting specialist for that client | Post what was paid, open a follow-up with the payer, or adjust if the client's terms say so. |
| Payment with no match | A payment or deposit with no expected payment on any claim line for that client. | Reconciliation lead | Search other open items, then keep it in the named reviewer's queue until the owner is identified. |
| Duplicate remittance | Same payment reference or trace number seen before. | Posting specialist | Confirm it is a duplicate and set it aside without posting twice. |
| Unusual adjustment | Adjustment or reason code outside the pattern the team has seen for that payer. | Senior specialist | Confirm against the payer's explanation, then post or escalate to the client contact. |
| Client-boundary doubt | A payment that could belong to more than one client account. | Controller or reconciliation lead | Resolve ownership by hand before any posting. Never auto-assign. |
Two documented behaviors make some of these checks easier. The vendor's documentation says "You can assume an ERA is a duplicate if the Check or EFT Trace Number is the same." [2] For the trace number, it says "You can use this value to link the ERA with the associated payment, if applicable." The trace number is therefore a good first candidate for the stage 2 link; test it against your own remittances [2].
For how to build the approval step itself, see document review with human approval. For matching rules and exception design in general, see reconciliation match rules and exceptions.
How does a 360 AI Blueprint approach this for a billing company?
A 360 AI Blueprint treats ERA reconciliation as one candidate workflow among several in your operation and ranks it with the others before anything is built. The ranking uses your volumes, your client systems and the state of your data, so the order reflects your firm. Our 360 AI Blueprint page describes the engagement.
| Factor | What it asks | Pushes the workflow up when | Pushes it down when |
|---|---|---|---|
| Volume and effort | How many remittances and exception items does the team touch per period? | Posting is a large share of the team's hours. | Volume is low enough that a spreadsheet works. |
| Route variety | How many remittance routes and file formats feed the clients? | Many routes, so ingestion is the bottleneck. | Every client already arrives through one clean route. |
| Data consistency | Are expected payments recorded the same way across clients? | Records are comparable, so matching is possible. | Expected payments live in notes or memory. |
| Cost of an error | What does a misapplied or missed payment cost the client relationship? | Errors are costly and found late. | Errors are cheap and caught the same day. |
| Review capacity | Can the team review flagged items every week? | A named reviewer exists per client. | No one has time to review, so the queue would grow. |
The factors compare workflows, not vendors. The Blueprint fills this table with your baseline, then compares reconciliation with the other workflows in your operation, such as the denial work described in denial management across clients. A purpose-built reconciliation tool may rank first for you, and the Blueprint should say so if it does.
Does this scale as client count grows?
Largely, when a new client adds only setup: a remittance route, a field map, expected-payment records and a reviewer. The matching rules, exception types and approval rule are common to every client.
- Per client: route, field map, expected-payment source, tolerance rule, reviewer.
- Shared: the standard remittance record, the exception taxonomy, the approval rule and the audit trail.
- Watch reviewer queue age, the share of items in the general queue, and rules the team keeps overriding.
- Ceiling: review capacity. If it does not grow with the client count, flagged items wait longer, so add clients only when reviewer queues are clear.
When this doesn't apply
- With a handful of clients, one remittance route and low volume, a spreadsheet or the matching tools already in your practice-management system may be the better choice.
- If expected payments are not recorded anywhere, there is nothing to match against. Capture them first; software cannot supply them.
- If your clearinghouse already pairs each ERA with its bank deposit and lists those with no deposit, use that report and automate only what it misses.
Where to start: a first scoped workflow
Replay recent ERAs from a single payer through two or three client accounts, with a reviewer checking each result before any live posting.
- Pick the payer feed
Take one payer's ERA feed and two or three clients that receive it, ideally with different deposit accounts.
- Define the remittance record
List the fields every ERA must yield, trace number included, and map each client's route to them.
- Name the exception owners
Agree the five types in the table above, or your own, in plain language, with one owner each.
- Set the tolerance
Write down how large a difference may be before it becomes an exception, and who owns that rule.
- Replay last month's ERAs
Run them through the matching while posting continues as today. Note each ERA where the result differs from what was posted.
- Pick reconciliation measures
Track the share of ERAs that tie to a deposit, near matches approved versus edited, and queue age per client. Take a baseline for each.
- Add one feed or client
Bring in one more payer feed or client at a time, updating the field map and exception owners.
The financial reconciliation automation page describes how this pattern is built and handed over.
Frequently asked questions
How do you reconcile payer remittances across multiple client accounts?
Ingest each electronic remittance advice into one standard record, then match payments and claim lines to that client's expected payments, one client at a time. Flag whatever does not tie out and send it to a named reviewer. Nothing posts until a billing or finance team member approves it.
What does an agent automate in payment posting?
It automates preparation. The agent parses remittance data, matches it to expected payments within a single client, drafts the posting entry with evidence attached, groups exceptions and logs approvals. It does not decide whether a short payment is correct or whether to write off a balance. A posting specialist approves each entry.
Who reviews an unusual or partial payment?
A person on the billing or finance team, ideally a named reviewer for that client account. The software flags and explains the item, and the reviewer decides to post, adjust, hold or go back to the payer. Which role holds that authority is the organization's own operating choice.
How does a 360 AI Blueprint approach this for a billing company?
It treats ERA reconciliation as one workflow among several and ranks it with your own data: volume, remittance route variety, data consistency, cost of an error and review capacity. The result is a ranked list before any build starts. It may show that a purpose-built tool fits better than a custom agent.
Does this scale as client count grows?
Largely, when a new client adds only setup: a remittance route, field map, expected-payment source, tolerance rule and reviewer. The matching rules and exception types stay shared. Review capacity still sets the ceiling, so watch queue age per client and add accounts only when queues are clear.
Related reading
- For how the reconciliation pattern is built and handed over, see financial reconciliation automation.
- For how a review step with a named approver works, see document review with human approval.
- For how workflows are ranked before a build, see the 360 AI Blueprint.
- For matching rules and exception design, see reconciliation match rules and exceptions.
- For the denial side of the same billing back office, see denial management across clients.
- For the wider picture of automation in billing companies, see medical billing and RCM automation.
Sources
- Stedi, "Differences between ERAs and real-time claim status checks" (accessed 2026-10-29)
- Stedi, "835 Electronic Remittance Advice (ERAs)" (accessed 2026-10-29)
More in Receivables and collections
Claims Scrubbing and Submission: What to Automate vs. What Stays Human-Reviewed
Claims scrubbing and submission: which checks to automate, which stay with a billing specialist, and a matrix to sort your own claim edits by who decides.
Medical Billing and RCM CompaniesAI Agents for Customer Deduction and Chargeback Management in Food & Beverage
Customer deduction chargeback management for food and beverage: a six-step coding and dispute workflow showing what an agent prepares and your analyst decides.
Food and Beverage ManufacturersStandardizing Denial Management Across Clients: An Implementation Guide for Billing Companies
Denial management across clients for billing companies: a five-stage workflow to normalize categories, route work queues and keep appeals with specialists.
Medical Billing and RCM Companies