Re-imports and late money

Billing data is never finished. Claims get corrected. Insurance settles weeks after the session. Somebody fixes a service code that was wrong all along.

This page explains what Track 2 Pay does about all of that — and why you can re-import as often as you like without breaking anything.

Re-importing is safe

Upload the same file twice and you do not get two copies of everything.

Every session and every clinician carries a unique identifier. When a row arrives, Track 2 Pay looks that identifier up. If it already exists, the existing record is updated. If it does not, a new one is created.

If your billing export does not supply identifiers, Track 2 Pay generates them from the content of the row itself — a session’s date, type, description and clinician; a clinician’s name and type. So duplicate detection works either way.

This is why the summary at the end of an import splits its counts into new and updated. Re-import an overlapping period and you should see mostly updated. If you see mostly new, something about the identifiers has changed — see when a re-import creates duplicates below.

Always import the newest file. Track 2 Pay applies what it is given. If you upload an older export over a newer one, you will overwrite good data with stale data.

When a payment amount changes

What happens depends on whether you have already paid for the session.

If the session has not been through a finalized payout, the payment is simply updated. The new amount replaces the old one and the next payout uses it. Nothing to think about.

If the session has already been paid, Track 2 Pay does not touch the original. Instead it records the difference as a new adjustment. The original payment, the original payout and the original rate all stay exactly as they were, and the new money is handled separately.

This is what keeps a closed period closed. A finalized payout is a record of what you paid somebody — it must not change retroactively.

Late money, paid at the original rate

The adjustment described above turns up in your next payout as a past payment.

Here is the part that matters: it is paid out at the rate that applied when the session originally happened, not at whatever your rules say today.

An example. In January a clinician was on 50%. A session collected $60 from the client, so they earned $30, and January was finalized. In March the insurer settles the remaining $120 on that same session. By then the clinician is on 60%.

The $120 pays out at 50% — $60 — because that is the deal that applied to that session. It appears in March’s payout under Past Payments.

You do not configure this or trigger it. Import the updated billing data and it happens. Each calculated line stores the rule and rate it used, which is what makes it possible.

Corrections that are not just money

Sometimes what changes is not the amount but a field — a service code, an appointment type, a corrected insurer.

If the change touches something Track 2 Pay uses to build the identifier, the corrected row may not match the original. It arrives as a new session instead, and now you have two records for one real appointment.

Track 2 Pay catches this. The stray record is dated inside a period you have already paid, so it shows up in Integrity Checks, with the original offered as a candidate and the differing field spelled out — Service Code: 90834 → 90837.

You confirm it is a duplicate, and the two are merged. See integrity checks.

When a re-import creates duplicates

If a re-import produces a wave of new records where you expected updated ones, something changed in the identifiers. The usual causes:

The clinician’s name is spelled differently. “Maya Ellison” versus “Dr. Maya Ellison”. This creates a second clinician as well as duplicate sessions. Fix the spelling at the source, or give the clinician a stable Provider Unique ID.

A description was edited. If you are relying on generated identifiers, editing a session’s description changes its fingerprint. Supplying your own Transaction Unique ID avoids this entirely.

Group sessions are collapsing or splitting. Group therapy needs the client’s name as part of the identifier, or several attendees at the same time look identical. If your account has Group Session Service Codes configured, this is handled; if not, ask support to set it up.

The timezone changed between imports. A different timezone shifts times, which shifts the fingerprint. Use the same timezone every time — set your account default and leave the field alone.

Undoing a session that should not have been paid

If a session went through a finalized payout and should not have, do not delete it — that would tear a hole in a closed period.

Void it instead. Open the transaction and use the void (dollar-off) button. Track 2 Pay adds an offsetting line named Manual Adjustment that brings the total to zero. The original stays visible; the correction sits beside it; the next payout picks up the negative adjustment and squares the clinician’s account.

See transactions and payments.

A rhythm that works

Import the newest export covering the new period, overlapping the previous one if that is easier.
Check the new/updated split. Mostly updated on the overlap is correct.
Clear the integrity checks. Duplicates from corrected fields will be waiting there.
Create the payout. Past payments appear on their own; you do not have to go looking for them.
Read the per-clinician table, then finalize.

Do that each period and late insurance money, corrections and re-imports all take care of themselves.