The Cash Flow Shape of Rebate-Heavy Work

Why this matters

A shop that files a handful of claims a year experiences rebates as paperwork. A shop where a majority of replacement work carries a claim is running a second operation alongside the first, with its own intake, its own backlog, its own busy season and its own failure mode, and almost nobody has staffed it as such. The tell is always the same: the coordinator is drowning in a month when the install schedule looks light, and nobody can explain why. The explanation is structural and predictable, and once you can see the shape you can staff against it instead of reacting to it.

Three clocks run on a rebate-heavy job

They start at different times, run at different speeds, and only one of them is yours.

Your invoice clock starts at completion and ends when the customer pays on your terms. This is the only one you control, and if your contract was written correctly it is entirely independent of the other two.

The incentive clock starts at submission, not at install, and ends when the administrator pays. Its length is set by a queue you cannot see. It commonly runs in months, and the tail is longer than the median by a wide margin.

The audit clock starts at payout and runs to the end of whatever verification or clawback window the participation agreement states. Nothing happens on this clock most of the time, which is exactly why shops close and archive the file before it expires, and why the one recovery notice that does arrive lands on a job nobody can document any more.

Confusing the first two is what makes a profitable rebate-heavy shop feel broke. The work was earned and invoiced on your clock; the thing the customer is waiting for is on a different clock entirely and was never your money. If that separation is not yet automatic, read the sibling card on cash versus profit before this one.

The claim queue is a second business

Model it the way you would model your service board, because it behaves the same way. A queue has an arrival rate, a time in system, and a resulting backlog, and the backlog is simply the arrival rate multiplied by how long each item stays open. That last relationship is the one shops miss, because they staff against arrivals ("we file about six a week") and get billed by the backlog.

Two costs come out of it, and they scale on different things:

• Origination cost scales with arrivals. Assembling and submitting a package, once per claim.
• Carrying cost scales with the backlog. Status handling, customer check-ins, chasing an administrator, re-answering a question about a claim filed nine weeks ago. Small per claim, per week, and multiplied by every open file you have.

A shop that only counts origination will conclude its claim work is cheap and will be wrong by a factor that grows with how long the administrator takes.

Worked example: the queue that will not close

A shop's coordinator has 12 hours a week available for claim work. The shop originates 6 new claims a week during the season. Median time from submission to resolution on this program is 9 weeks. Measured from the shop's own time records: origination runs about 1.2 office hours per claim, and each open claim consumes about 0.25 office hours per week in status handling.

Steady-state open claims: 6 per week times 9 weeks equals 54 open files at any moment.

Weekly load:

• Origination: 6 times 1.2 equals 7.2 hours
• Carrying: 54 times 0.25 equals 13.5 hours
• Total: 20.7 hours per week against 12 available

The queue is short by 8.7 hours a week, and it will not fix itself. What actually happens is that the coordinator drops the discretionary half first, which is the proactive status handling, because origination has a deadline attached and check-ins do not. Customers then call in to ask where their money is, and an inbound status call costs several times what the outbound message it replaced would have cost. The deficit widens by exactly the behavior the deficit caused.

Now look at where the load actually sits. Carrying is 13.5 of the 20.7 hours, about 65 percent. Origination, the part everyone thinks of as "doing the rebate," is 7.2 of 20.7, just over a third. So a fix aimed at filing faster changes almost nothing, and this is the most common wrong move: shops buy a better submission template and wonder why the coordinator is still underwater.

Fix the two terms that dominate. Capturing documentation at the job rather than reconstructing it, plus a standing package template, brings origination from 1.2 to 0.7 office hours. Replacing ad hoc status handling with a scheduled check-in every 3 weeks brings the per-open-claim weekly cost from 0.25 to 0.12 hours, because the message is written once and sent on a rhythm instead of being composed in response to each call.

Recalculated on the same volumes:

• Origination: 6 times 0.7 equals 4.2 hours
• Carrying: 54 times 0.12 equals 6.48 hours
• Total: about 10.7 hours per week against 12 available

The queue now closes with about 1.3 hours of slack, on identical claim volume, an identical administrator timeline and the same one coordinator. Nothing was outsourced and nobody was hired. The change was to attack the term that scales with backlog rather than the term that scales with arrivals.

One caution on that slack: 1.3 hours is thin, and the 54-file backlog assumed a steady 6 arrivals a week. It will not stay steady, which is the next section.

The seasonal trap: your admin peak lags your install peak

Arrivals follow your install schedule, so they spike in your busy season. The backlog is arrivals multiplied by time in system, so the backlog peaks roughly one full claim-lifetime after the arrival peak. On the numbers above, that is a lag of about 9 weeks, better than two months.

The consequence is specific and it catches shops every year. Your open claim count peaks in the shoulder season, when the install board has gone quiet and the instinct is to trim office hours because "things have slowed down." Things have not slowed down in the office. They have peaked there, on a lag, while slowing down everywhere else.

Denials arrive later still, because a claim is worked before it is refused, and denial handling is the most expensive kind of claim work: reading the reason, deciding whether it is fixable, resubmitting inside a window, and calling a customer with news they will not enjoy. So the sequence across a year runs install peak, then submission peak, then payout and status peak roughly a claim-lifetime later, then a denial-handling tail after that. Staff and schedule against that sequence rather than against the install calendar.

The phantom receivable

Where the program pays the customer, and that is most programs, the incentive never appears anywhere in your books. There is no receivable, no revenue and no line item. What exists is a real cost, paid in office hours, attached to money you will never touch.

That invisibility is the problem. Costs that do not show up do not get managed, and a shop can spend a meaningful share of its office capacity on claim work for years without a single number on any report reflecting it. Fix it with a cost code: track claim administration hours as their own category, by program. Two things fall out immediately. You learn which programs are expensive to run relative to what they deliver to your customers, and you can see the seasonal shape described above instead of experiencing it as a mood.

Where you are contractor-of-record and the program pays you, the opposite issue applies: you do have a receivable, and it ages on a profile nothing else in your books resembles. Do not let it sit inside your ordinary customer aging report, where a 90-day item reads as a collection problem. A 90-day program receivable may be entirely normal on that program, and mixing the two makes both unreadable.

Three numbers worth tracking, and what each tells you

Open claims outstanding, counted weekly. This is your backlog, and it is the number that predicts your office load 1 to 2 weeks ahead. A rising count during a flat install schedule means the administrator has slowed down, not that you are filing more.

Median days from submission to resolution, per program, with the longest case shown beside it. The median sets your customer communication expectations. The longest case is what stops you from panicking at week 12 and, more usefully, it is the number you quote internally so nobody escalates a claim that is behaving normally.

Office hours per claim, split into origination and carrying. The only number that tells you whether a program is worth running as an administrative line at all, and the only one that will show you the 65-percent-is-carrying result before it costs you a season.

Track all three per program. Aggregating across programs hides the one that is quietly consuming a disproportionate share of the coordinator's week.

When not to file at all

Some claims cost more to run than they deliver to anybody. That is a legitimate finding and it deserves a shop-level decision rather than a coordinator quietly deprioritizing files.

A workable screen: if a program's claims cost more than 1.0 office hour each in combined origination and carrying, and the incentive is worth less than a tenth of the ticket to the customer, that program is a courtesy you are choosing to provide, not an administrative line that pays for itself. Decide it deliberately, at the shop level, per program, and either commit to it as a service you are proud to offer or stop naming it to customers altogether. What you must not do is keep offering it and then handle it badly, which is the outcome that produces both the cost and the complaint.

The reverse case is worth naming too. A program with a high incentive relative to ticket, a short queue and a clean documentation set is worth actively steering customers toward, and the shop that measures its programs is the only one that knows which of its programs that is.

References

• Program administrator participation agreement, which states the audit or clawback window that governs how long the claim file must be retained
• IRS Publication 583, Starting a Business and Keeping Records, on retaining records supporting items reported on a return
• See related: Cash vs Profit: Why They're Different; The Program Eligibility Check SOP; How to Decide Whether to Front a Rebate for a Customer