Solar milestone payments and the clawback clock

If you run a residential solar installation business, the hard part is no longer just getting the job sold or installed. It is knowing where the money sits on every open job, which funder gate it is waiting on, and when a missed PTO deadline could claw back the install payment.

That is what solar milestone payments are really about in 2026. For most TPO-funded jobs, the contract does not pay at signing. Most of the money arrives after the install package is approved, and a smaller holdback arrives at PTO, short for permission to operate. The practical job for the owner is to track each project against one internal milestone model, one clawback clock, and one weekly review that shows cash at risk.

This article explains how to normalize the labels, what the milestones mean, and how to turn a messy mix of funder portals and spreadsheets into one funding view you can actually manage.

The milestones in one internal model

Funders use different labels for the same basic sequence. Internally, it helps to map every job to one gate model, even if the funder calls the steps M0, M1, M2, or something slightly different.

The details vary by contract and funder. The pattern is usually the same: contract signing creates the job, install approval releases most of the dollars, and PTO releases the rest or confirms the final holdback.

Palmetto’s 2026 help articles describe M1 and M2 submission workflows, which is a good example of how funder labels can differ from the installer’s own language. R11’s TPO milestone materials describe the same underlying economics: little or nothing at contract, most value after install, and a holdback tied to PTO. See Palmetto’s M1 and M2 submission guidance and R11’s TPO milestone payment overview.

That is why a normalized internal model matters. If your CRM says the job is “in progress” while the funder portal says “M1 rejected” and finance is waiting on a PTO holdback, you do not have one status. You have three different versions of the truth.

Where the money actually waits

Most delays happen in three places.

• Install package review lag. The job is physically complete, but the funder has not approved the evidence package yet.
• Rejection and resubmission. Something in the package is incomplete, inconsistent, or outside the approved design, so the clock stops until the issue is fixed.
• PTO on the utility clock. The installer may be done, but the utility still controls the last step.

That matters because each delay has a different owner. A missing photo, a mismatched serial number, or an as-built that does not match the approved plan is usually fixable inside your operation. A slow utility PTO is not. If you do not split those causes, you will overestimate how much of the delay is actually under your control.

For a working report, use simple states such as submitted, under review, rejected, resubmitted, install approved, PTO pending, and paid. Then attach the reason code to every rejection. The reason code is where the process problems show up.

The clawback clock is a live metric, not a footnote

In many TPO programs, the install payment is not truly safe until PTO lands inside the funder’s deadline window. If PTO slips past that window, the installer can lose some or all of the held amount. That is the clawback risk.

The exact timing depends on the contract and funder. The operational point is simple: every funded job needs a deadline date, a days-remaining field, and an owner for the blocker.

A useful definition is:

Clawback clock = funder deadline date minus today.

You can also track age from install to today, then compare it with the contract window. For example, if the contract allows 120 days from install to PTO and a job is already 94 days past install, you are inside the danger zone even if the utility process is still moving.

Sort jobs by days remaining, not by install date alone. Then split them into two groups:

• Utility-side blockers: interconnection review, inspection backlog, utility corrections, PTO issuance.
• Installer-fixable blockers: missing docs, bad photos, form errors, plan mismatches, customer signature gaps.

The point of the clawback clock is not just to warn you. It tells you where a repackaged task, a call to the utility, or a same-day office fix can protect cash.

Rejections are data, not just noise

If you only track whether a job was rejected, you miss the business lesson. The useful question is which funder rejects which package type, for which reason, and how often first-pass approval succeeds.

Track each rejection with at least these fields:

• funder
• job ID
• milestone stage
• rejection date
• reason code
• who fixes it
• resubmission date
• outcome

The sources linked above, plus common funder guidance, point to a few recurring causes: photo packages that do not meet requirements, as-builts that diverge from approved plans, and interconnection application errors. Those are useful because they are usually fixable through process, training, or a better checklist.

Once you capture the reason codes, calculate first-pass approval rate by funder and by flag type. If one financier rejects a high share of jobs for photo issues, that is not just a portal problem. It is a coaching problem, a field QA problem, or both. If another funder is strict on as-builts, your design-to-install handoff may need tighter controls.

The five numbers to review every week

You do not need a large dashboard to start. You need five numbers that show whether funding is moving and whether cash is getting stuck.

• Installed but unfunded dollars. Jobs that have passed install but have not yet cleared the main payment gate.
• Submitted and awaiting review dollars. Packages sitting in a funder queue.
• Rejected and open dollars. Jobs that need rework before the next submission.
• PTO pending by age band. Separate jobs at 0-30, 31-60, 61-90, and 90+ days since install or since M1, depending on the contract model.
• Jobs inside 30 days of clawback. The highest-priority cash risk.

Run that review for the whole company, then break it down by funder, by package type, and by office or crew if the data is clean enough. The goal is not reporting for its own sake. It is to answer one question: where is cash floating, and what can we do this week to move it?

A 30-minute weekly agenda is enough:

• Review the jobs inside the clawback window.
• Look at the rejected jobs and the top reason codes.
• Check which funder queues are aging.
• Call out any PTO blockers the team can actually influence.
• Assign owners and due dates for the highest-value fixes.

What your CRM tracks well, and what it usually misses

Most CRMs and project tools are good at stages, tasks, and documents. They are less useful when you need to normalize funder-specific milestone labels, compute a clawback clock, and compare rejection rates across financiers.

That is because the CRMs are usually job-centric, while funding is gate-centric. A project manager wants to know whether the site survey is done. Finance wants to know whether M1 cleared, whether PTO is pending, and how much cash is at risk if the utility drags.

Funder portals make the problem worse because each one is a separate silo. You end up copying the same job into a CRM, a portal, and a spreadsheet, then reconciling them by hand.

There is one architectural point worth making for operators who already run sales, install, and service in separate systems. The funding record is most useful when it sits on the same data as the sales and install record. That is the kind of operating software Better builds for energy businesses, including solar installers like Sunny Energy, and it is why the funding model should be part of the core job record rather than a side spreadsheet. See Better for energy companies.

Spreadsheet first, point tool next, custom build last

For many installers, a spreadsheet is the right starting point. It is cheap, visible, and fast to change. If you are managing a modest number of concurrent TPO jobs and the team can update it every week, a spreadsheet can carry the basics: job ID, funder, gate, deadline, rejection reason, and cash amount.

A point tool makes sense when the manual work starts to consume office time or when the team cannot keep the data current. Tools such as R11 exist for milestone payment tracking, and that can be enough if your process is close to the tool’s model.

Build something custom when at least one of these is true:

• you work across multiple funders with different milestone rules and labels
• your operating data needs to connect funding with sales, install scheduling, and service
• you finance cash flow internally and need a cleaner view of exposure
• the office team is already spending too much time reconciling portals by hand

The threshold is not a specific job count. It is whether the cost of bad visibility is larger than the cost of maintaining a better system. If you cannot answer, in one screen, how much money is installed but still unfunded, it is time to tighten the model.

How to set up the per-job funding record

Keep the record short enough that people will actually use it. The useful fields are:

• job ID and customer name
• funder and contract type
• internal gate: M0, M1, M2, or M3
• funder label and submission date
• install date and PTO date target
• deadline date for clawback risk
• amount expected at each gate
• current status
• last rejection reason
• next action owner

If a field does not change a decision, leave it out. The aim is not to build a database for its own sake. It is to give the owner and finance lead one place to see the state of cash by job.

If you adopt only one change this week, make it the clawback clock. Once every open job has a deadline and an owner, the other parts of the report become much easier to manage.

FAQ

What does M1 mean in solar?

M1 usually means the first major funding milestone after installation, but the exact label depends on the funder. In many TPO programs, it is the stage where the install package is approved and most of the money is released.

What is M0, M1, M2, M3?

These are milestone labels some funders use to describe the funding sequence. A common internal mapping is contract signed for M0, install approval for M1, PTO for M2, and any later settlement or reserve release for M3. Contracts vary, so always map the funder’s labels to your own internal gates.

What is the difference between NTP and PTO?

NTP means notice to proceed. It is the point when a project is authorized to move forward. PTO means permission to operate. It is the utility approval that lets the system operate on the grid. NTP starts the work; PTO ends the utility side of the process.

What happens if PTO misses the deadline?

It depends on the contract, but the risk is that some of the install payment can be clawed back or delayed. That is why the deadline and the blocker owner should be tracked for every funded job.

What does TPO stand for in solar?

TPO stands for third-party ownership. In this model, a financier or third party owns the system, and the installer is paid through milestone releases instead of at full contract signing.