Late-coded encounters: reconciliation rules that hold up

An encounter is late-coded when its coding is finished after the cut-off for the period it belongs to. It then misses that period’s productivity, revenue or quality numbers, and either reopens a closed period or is fixed by hand. This guide sets out the rules that settle it once: which date a record is counted on, what happens after the cut-off, the audit trail that explains every change, and how to keep late records from skewing a model.

Written by the Netspective healthcare data practice · Last reviewed 29 October 2026

Why late coding moves the numbers

Documentation is completed after the visit, coding queues build up, and charges post days or weeks after the date of service. Meanwhile the reporting period closes on a fixed day. Every encounter that is still uncoded on that day is missing from the closed numbers, so a physician’s work RVUs, a department’s revenue or a quality measure’s denominator are understated, and they change when the late records finally arrive.

Without a written rule, each team handles this differently: one reopens last month, another adds the records to this month, a third adjusts a spreadsheet. The totals then disagree, and nobody can say which is right.

Choose the date a record is counted on

The first rule names the attribution date. There are three common choices.

Three attribution dates and their trade-offs
Attribution date	What it gets right	What it costs
Date of service	Counts work in the period it was done.	Closed periods keep changing as late records arrive.
Date coded or posted	Closed periods never change.	Work is counted in the wrong period, and coding delays look like productivity swings.
Date of service with a carry-forward	Closed periods stay closed, and each late record is counted once, in the next open period, flagged with its original service period.	Needs the audit trail below, so a reviewer can see what was carried and why.

Many organizations settle on the third, but the choice belongs to finance and operations together, and it should be written down before any data is built on it.

Write the carry-forward rule

A rule that holds up names five things:

The cut-off. When a period closes, for example a set number of business days after it ends.
Where late records go. Into the next open period, keeping their original service period as a separate field.
The age limit. How old a record can be before carrying it forward needs a named approver.
Corrections and voids. A reversal and a new entry, never an overwrite, so the closed total can still be reproduced.
The rule’s version. When the rule changes, which records were counted under which version.

A worked example

Suppose March closes on the fifth business day of April, which in 2026 is 7 April. An encounter on 28 March is coded on 9 April. Under a date-of-service rule with a carry-forward, it is counted in April, flagged as carried from March. March’s published total stays as it was, April’s includes the record, and a reconciliation report lists it under both: service period March, counted period April, arrived 9 April, rule version 1.

Keep an audit trail for every carried record

The question every reviewer eventually asks is “why did this number change?” The answer needs, for each carried record: the source record identifier, the date of service, the date it was coded, when it arrived in the data platform, the period it was counted in, the rule version applied and the reason. Kept append-only, those fields let anyone rebuild a closed period’s total exactly as it was published, and trace any reported value back to its source records.

Keep late records from skewing a model

Models trained on encounter data meet the same problem in a quieter form. If a feature is computed from today’s complete data, but at prediction time the late records have not arrived yet, the model learned from information it will never have when it runs. Build features as of a date: join on when each record arrived, not only on its service date, so a training row sees exactly what was known at that moment. Carry the late-arrival flag into the feature set, and use the same as-of logic in training and in production.

Checklist

The attribution date is written down and agreed by finance and operations.
The cut-off and the age limit for carry-forwards are stated, with a named approver for exceptions.
Late records keep their original service period in a separate field.
Corrections are reversals plus new entries; nothing in a closed period is overwritten.
Each carried record has an append-only audit entry with the rule version.
A reconciliation report shows, per period, what was carried in and out.
Model features are built as of each record’s arrival time, the same way in training and production.

How Netspective works on this

Netspective assessed an existing data flow and designed a proposed architecture for productivity-based physician compensation reporting, including how late-coded encounters carry into a later payment period. The case study sets out that design work and what its records do not establish. In a healthcare data lake engagement the reconciliation rules are agreed during discovery and implemented in your own tenant.

Sources

Centers for Medicare & Medicaid Services, Physician Fee Schedule (relative value units, including the work RVU).
Netspective, physician compensation data case study (late-coded encounters and calculation cut-offs in a proposed design).

Get the checklist and future updates

One field. We send this guide’s checklist and a note when the guide changes, and nothing else. Your email is read only by Netspective administrators and deleted after 24 months.