Auto-Posting Rules

Automated posting is worth doing, and where a remittance can be posted automatically it usually should be. Software matching a structured remittance to structured claims is faster and more consistent than a person keying it line by line, and manual keying introduces exactly the transcription errors that How Payment Posting Works is about. Federal guidance describes the electronic remittance, once reassociated with its payment, as something that enables a provider to auto-post payments to its receivables. The engine reads the payment and the coded adjustments off the transaction and books them against the accounts.

On every line the engine makes two decisions in sequence. First it matches — pairs the remittance line to the claim and line it belongs to. Then it decides post or hold — book the amounts and close the balance, or route the line to a person in an exception queue. The whole subject of auto-posting rules is that second decision, and the reframing that matters is this: every automatic post is a decision made once, in a rule, and then executed forever without anyone reviewing it again.

That changes what you are actually designing. You are not writing rules for the lines the engine should post — a clean, matched, expected line needs no rule beyond a default to book it. You are writing rules for the lines it must not post on its own: the conditions under which it has to stop. The quality of a rule set lives entirely in its hold criteria, because those are the only part whose job is to keep a balance open when closing it would be a mistake.

The hold criteria are a short list of situations where an engine has no business closing a balance by itself. Each of these belongs to another article that owns the task in full; the point here is only that a rule set is the thing that recognizes them and routes the line instead of posting it.

• A line that did not match a claim, or matched more than one. There is nothing to post it against, and forcing it onto the closest-looking account is one of the ways a payment becomes unapplied cash — money holding in suspense while the account it truly belongs to still shows outstanding.
• A denied or zero-pay line. An engine can record the zero, but the work a denial creates — reading the reason and group codes, deciding whether to appeal — is a person's, and Reading a Denial owns those codes. A rule that closes a denied line as though it were resolved buries the very thing that needed working.
• An adjustment carrying a code the rule set does not recognize, or does not expect on that kind of claim. An unmapped or surprising code is by definition the case the rules cannot handle — routing it to a person is the only honest outcome.
• A provider-level amount. An offset or recoupment and a late-payment interest amount ride on the remittance but are not payments on any current claim; posting them as though they were invents false claim activity. How each is posted belongs to Posting a Payer Offset and Posting a Payer Interest Payment.
• A line whose secondary billing or patient balance turns on detail the automatic path would flatten. A secondary claim has to carry what the primary did; a rule that closes the primary without preserving that detail leaves nothing to send.
• A line whose amounts fall outside a tolerance the practice set. Including a contractual adjustment larger than the loaded contract implies — though, as below, a rule can only flag the discrepancy for a person, never resolve it.

The through-line is that each of these is a case where posting the line closes something that should have stayed open — an unresolved denial, an unbillable secondary, a suspense item, a possible underpayment. A rule set's real function is to keep those open. This is the concrete content of a general truth How Payment Posting Works states plainly: automation does not remove the difficult work, it concentrates it in the exception queue, and the queue is the job. The hold criteria are what decides what the queue contains.

What makes auto-posting possible at all is that the remittance is standardized. The electronic remittance is a structured, machine-readable transaction adopted as a national standard, and its adjustments are coded — a claim-adjustment group code naming the category of an amount, paired with a reason code that names the specific reason. Industry operating rules push the standardization further, maintaining a defined set of allowed combinations of those codes mapped to a small number of business scenarios, precisely so that the same situation is expressed the same way on every payer's remittance and an engine can map it to an action. That coded, standardized structure is the substrate a rule set is built on.

But it is worth being exact about what a rule can and cannot read from that structure. It reads a category, and it routes on the category. It cannot read a magnitude. A group code tells the engine that an amount is the provider's contractual obligation to absorb, or the patient's responsibility to pay; it never tells the engine that the amount was the size the contract actually required — and no code does. So a rule can send a contractual-obligation adjustment down the auto-post path entirely correctly, judged by category, and be closing a balance over a shortfall. Checking the size of that adjustment is a different control, the one Validating Contractual Adjustments owns, and it needs a reference the engine does not hold: the loaded contract. The rules route; they do not validate.

Manual posting produces scattered transcription errors — a wrong figure here, a mis-keyed account there, each one its own mistake. A rule produces one error, repeated. A mapping that sends a code combination to the wrong bucket does it to every line that matches, at volume, without a moment of hesitation, which is exactly what a person doing it by hand would not do. Automation removes the typing error and scales the configuration error. That trade is worth making, but it is a trade, and it decides how a rule set has to be treated: because a wrong rule is systematic rather than occasional, the rule set is an artifact to be governed, not a convenience to set once and forget.

• Change control. A change to a rule is a change to how every future remittance posts. It is reviewed and recorded, with a reason, not edited live on a hunch.
• Test before it runs live. A new or changed rule is run against known remittances and its postings checked before it is turned loose on volume — the cheapest place to catch a mapping that closes what it should have held.
• Sample what auto-posted. The auto-post path produces no exceptions by definition, so nothing surfaces its errors unless someone deliberately looks. Reviewing a sample of what closed automatically is the only feedback the silent path gives.
• Reconcile regardless. Auto-posting does not relieve the completeness control; the cash still has to be proven against the bank, which Payment Reconciliation owns. An engine that posts everything perfectly against the wrong total still has to answer to the deposit.

And a rule set is never finished, because the codes it reads do not hold still. The reason and remark code lists are externally maintained and updated on a published schedule; payers and plans are added; contracts amend. A mapping that was complete last year silently drops the combinations added since into the unmapped-and-therefore-held pile — the safe failure — or, if a rule was written too broadly, posts them under an assumption that no longer holds, which is the unsafe one. Maintaining the rule set against the current code lists and the current payers is not preparation for the work; it is part of the work.

It follows that a rule set which holds too little is more dangerous than one that holds too much. The lines it wrongly holds are visible — they sit in a queue, waiting, costing time. The lines it wrongly posts are invisible — they closed. So the failure worth designing against is under-holding, and the measure of a good rule set is not how much it manages to auto-post but whether everything it does auto-post was genuinely safe to close without a human. A high auto-post rate bought by closing things that needed a look is not efficiency; it is loss that does not show up as loss.

But a hold is only half of a control. A line routed to an exception queue and then not worked is not resolved — it is a payment sitting in suspense while the account it belongs to still shows outstanding, the unapplied cash problem seen from the automation side. Everything else in Payments & Posting is about posting money correctly as it arrives; auto-posting rules are about deciding, correctly, which money the machine may post and which it may not. Good hold criteria move the judgment to one place. They do not do the judging — the queue still has to be worked, or the rule set has only relocated a backlog rather than prevented one.