The Rebate Submission SOP

Purpose

To get every eligible claim submitted complete, on time, and logged in a way that lets anyone in the shop answer three questions without asking a person: which claims are open, which one is late, and which payment belongs to which job. A claim that was assembled correctly and then sat in an inbox for three weeks is indistinguishable, from the customer's side, from a claim that was never filed.

Scope

Applies to every incentive program the shop administers on a customer's behalf, from job completion through payment reconciliation and customer notification. It does not apply to programs on the refer-only list, where the shop supplies documents and the customer files. It does not apply to incentives the customer claims directly on their own tax return, where the shop is not a party and the only obligation is to supply accurate product documentation on request.

Submission is downstream of capture. This SOP assumes the job-level capture card is complete or carries an explicit gap flag; it does not re-specify what gets photographed at the job.

Roles and responsibilities

Definitions

• Claim. One submission to one program for one job. Two programs on one job are two claims with two logs and two clocks.
• Confirmation number. Whatever reference the program returns at submission. A submission without a captured confirmation reference is treated as not submitted.
• Cure window. The period after a rejection in which a corrected claim is still accepted. It is set by the program, it is usually shorter than the original filing deadline, and it starts running on the rejection date, not on the day you opened the mail.
• Chase date. The date the coordinator contacts the program about a claim that has not paid. It is set from the shop's own measured payment history, not from a brochure.

Procedure

1. Open the claim at job completion. Within 5 business days of completion, or within 5 business days of the inspection closing where the program requires a passed inspection, the coordinator opens a log row and pulls the capture card. Waiting for a monthly batch is the most common way a filing deadline gets missed on a job that was finished in plenty of time.

2. Re-read the program's current terms on the day of submission and record the version date. Terms, qualifying lists and required documents change mid-year, and the version that governs is generally the one in force when the work was performed. This step exists because the estimator's eligibility check happened before the sale, which can be weeks or months earlier. If the terms changed between the check and the install, resolve it now, before submitting, and tell the customer immediately if their eligibility moved.

3. Verify the date lattice. Purchase date at or before install date, install date at or before completion date, completion date inside the program period, submission date inside the filing deadline. Any inversion is either a data-entry error you can fix or a genuine eligibility problem you need to know about before you spend an hour assembling the rest.

4. Verify the claimant against the program's payee rule. Where the program pays the utility account holder of record, confirm the name on the application matches the account, not the person who signed your work order. This is a two-minute check that prevents one of the most common rejection classes, and it is unfixable after the fact without a fresh signature from a different person.

5. Assemble against the program's own checklist, not from memory. Work the program's required-document list line by line. If a document is missing, stop and get it. Do not submit a claim with a known gap on the theory that the processor might not notice: a processor stops at the first failed check, so an incomplete submission usually costs you a full cycle and returns only the first defect it found.

6. Submit and capture the confirmation reference immediately. Same session, into the log, before the next task. This is the step with the highest cost of omission on the whole SOP, because a claim with no confirmation reference cannot be chased, cannot be proven, and can only be resubmitted from scratch if it is even still inside the deadline.

7. Notify the customer, in the program's language. Tell them the claim was submitted, on what date, and what the program's own published window is if it publishes one. Add your own nine-in-ten mark as the "if it runs long" marker. Never give a date certain, never quote your median, and never say the amount is approved. See the sibling card on explaining incentives without overpromising for the wording.

8. Set the chase date. Set it at the shop's measured nine-in-ten payment mark for that program. If you have fewer than 10 paid claims of history with that program, start at 12 weeks from submission and replace it with your own measured number once you have 10. Escalate past the program's standard support channel at 1.5 times the chase interval.

9. Work information requests ahead of everything else in the queue. An information request carries a response deadline that is usually much shorter than anything else on your board, and letting it lapse converts a live claim into a closed one. It goes to the front regardless of how small the claim is.

10. Reconcile payment to claim on receipt. The bookkeeper matches the payment to a specific log row by confirmation reference or claim identifier, not by amount and not by customer name, because partial payments and multi-claim customers make both of those ambiguous. Then close the row and notify the customer that it landed.

11. Route rejections out of this procedure. A rejected claim leaves the submission SOP and enters rejection handling, with its cure window recorded on the log row on the day the rejection arrives. Do not attempt a same-day corrective refile against a rejection you have not fully read, because refiling against only the cited defect is how a claim gets rejected twice.

12. Batch the routine, never the deadline. Run submissions on a fixed weekly day so the work has a home in the calendar. The weekly batch is a scheduling convenience, not a permission to hold a claim: steps 1, 6 and 9 have their own clocks and override the batch day every time.

The submission log

One row per claim. These fields, and no free-text substitute for any of them:

Job identifier, customer, premises address, program name, terms version date, claim type, submission date, confirmation reference, program's quoted window if published, chase date, current state, last customer contact date, rejection date and cure-window end if applicable, payment date, payment matched by, closed date.

The log is the only artifact in this SOP that has to be maintained whether or not anything is happening, which is exactly why it gets abandoned. Judge it by one test: can somebody who was on vacation last week tell you which claim is closest to a deadline, in under a minute, without calling anyone.

Worked example: one log row at three moments

The same row, as it looks at submission, after a rejection, and at close. Effort figures are office hours; elapsed figures are weeks.

At submission. Job identifier recorded, program named, terms version read and dated that day, claim type equipment replacement, submission date recorded, confirmation reference captured in the same session, program's published window entered as given, chase date set at 12 weeks because this program has only 4 paid claims of history and the shop's own nine-in-ten mark does not exist yet, state set to submitted, customer contacted the same day with the program's window and the 12-week marker. Coordinator time to this point: 1.3 hours including assembly.

At week 5, rejection. Rejection date recorded the day it arrived. The cure window is entered as the program states it, counted from the rejection date rather than from receipt, which matters here because the notice sat two days in the mail. State moves to rejected, and the row is routed to rejection handling. The chase date is cleared, because a rejected claim is not a slow claim and leaving the old chase date on the row would have made the board read as if the claim were still healthy.

At week 11, close. Refiled in week 6 after correcting the cited defect and one uncited defect found on review, paid in week 11, payment matched to the confirmation reference of the refile rather than of the original submission, row closed, customer notified. Total coordinator time on the claim: 2.6 hours, against a shop ceiling of 2.0 hours per claim measured as a median. One claim over the ceiling is expected and does not move a median; if the next four claims on this program run similarly, the program's handling-time gate has failed and the program itself goes back to the owner for re-screening.

Escalation and exceptions

• A program changes terms mid-season. The coordinator stops submitting under that program the same day, flags every open claim filed under the superseded terms, and escalates to the owner before anything else goes out. Filing more claims under terms you know are stale is the single most expensive mistake available in this SOP, because the loss scales with your submission rate.
• A claim is approaching its filing deadline with a gap that cannot be closed. Escalate to the owner rather than submitting a knowingly incomplete claim. Sometimes the right answer is to submit and use the information-request cycle as the cure path; sometimes it is to tell the customer honestly that it will not be filed. Both are decisions, and neither belongs to the person holding the folder at 4 pm on the deadline.
• The customer asks you to change a date or a description so a claim will qualify. Refuse, in writing, and tell the owner. This is not a paperwork judgment call.
• A payment arrives that cannot be matched to any open row. Do not close the nearest plausible row. Hold it, find the claim, and if it belongs to a claim you had written off, that is a finding about the log, not a windfall.

References

• The current published terms, required document list and filing deadlines of the specific utility, manufacturer or state program, which override any timing in this SOP
• IRS, Instructions for Form 5695, Residential Energy Credits, for the boundary between programs the shop files and credits the customer claims directly
• See related: How to Capture Rebate Documentation at the Job; How to Track a Submission You Do Not Control; How to Handle a Rejected Rebate Claim; The Timeline Between Submission and Payment