A permit tracker should tell your team what to do next.

A green "submitted" label does not tell an installer whether the AHJ has the packet, whether corrections arrived, or whether anyone owns the next follow-up.

That difference is what you are buying.

Solar permit tracking software should turn every application into a traceable sequence of requirements, evidence, dates, decisions, and accountable actions. It should also show what permit approval changes for the rest of the business.

What is solar permit tracking software?

Solar permit tracking software is a system for recording and managing the status of solar permit applications across authorities having jurisdiction (AHJs). It should help an installer prepare the submission, capture the official application reference, record responses and corrections, assign follow-up work, preserve the approval record, and connect the outcome to installation readiness. It is not necessarily a permit-issuing system, an engineering design tool, or an automated code reviewer.

A useful buyer test is whether the product can answer six questions about a live project without a coordinator opening email: Which AHJ controls this permit? What exactly was submitted? What status is verified? How long has it been there? Who owns the next action? What happens to scheduling when the decision arrives? If the screen shows only "in progress," it is a project label, not meaningful permit control.

Why does the distinction matter in 2026?

Permitting is still a local process even when a contractor operates across multiple states. The U.S. Department of Energy's rooftop solar permitting guidance notes that jurisdictions differ in requirements and fees, and that administrative errors and backlogs can delay work. Software must accommodate those differences instead of assuming every town has the same packet, portal, review clock, or inspection rules.

Automation is also changing the landscape. A 2026 National Laboratory of the Rockies report analyzing 2024 SolarAPP+ activity found that 861 installers submitted 37,393 permits through the platform during that year. The researchers reported that participating SolarAPP+ projects were permitted and inspected a median 12 business days sooner than traditionally processed projects. That is a finding about the automated permitting pathway in the study, not evidence that purchasing a commercial tracker will save any installer 12 days.

What should you expect a tracker to do on day one?

Start with visibility that changes decisions. A coordinator needs a working queue of applications, not a colorful pipeline copied from sales. Each row should expose the AHJ, project identifier, current verified state, last official response, days in state, accountable employee, next action, and due date. The manager needs filters for corrections awaiting design, submissions without receipts, approvals waiting to be released, and projects that have exceeded the company's follow-up policy.

That does not mean every jurisdiction exposes an API or provides instant status updates. A trustworthy system distinguishes a status imported from an official source from one entered by an employee, shows when it was checked, and does not invent approval dates. Ask vendors to demonstrate how a coordinator updates a record when the AHJ communicates only by email or phone. Manual evidence capture is often a necessary capability, not an embarrassing exception.

Which permit stages should be tracked separately?

A generic "permitting" stage hides too much. The application may be awaiting internal engineering, ready to submit, submitted without confirmation, accepted for review, returned as incomplete, under technical review, awaiting applicant correction, resubmitted, approved with conditions, or finally issued. Your company may need fewer labels, but the system must preserve distinctions that affect action and timing.

Do not confuse permit issued with permission to operate (PTO). Building and electrical permit processes, inspections, utility interconnection, and PTO can be related but are not interchangeable. The DOE overview describes local permitting and inspection as distinct from the utility's connection decision. A good tracker can display related milestones together while retaining separate authorities, dates, and evidence.

What is the minimum data model for a useful permit record?

A buyer should ask to see the actual fields behind the dashboard. At minimum: project and site, AHJ, permit type, submission channel, application number, packet revision, submission date, receipt, official state, state effective date, last verified check, next follow-up, assigned owner, fees where relevant, correction cycle, approval conditions, and permit document. For multi-site commercial work, also ask about multiple permits per project and different reviewing departments.

The critical distinction is between a fact and a plan. "AHJ approved on October 12" is a fact that should have supporting evidence. "Expected by October 24" is a forecast. "Call reviewer Friday" is a task. Software that stores these as one date field creates misleading reports. During a demo, ask the vendor to show who changed each field, when it changed, and which attachment or official communication supports the entry.

How should the software handle jurisdiction-specific requirements?

An installer working in several cities cannot rely on one universal permit checklist. Requirements may vary by authority, project category, code adoption, equipment, structural conditions, storage configuration, electrical service changes, and local submission procedures. The tracking system should let the company maintain a jurisdiction profile with source URL, applicability, last verification date, responsible maintainer, required packet items, fee notes, and known exceptions.

A jurisdiction profile is an internal operating aid, not a substitute for the AHJ's current instructions. Ask whether a user can mark an item "needs re-verification" when a form changes, retain the previous version for audit, and identify projects affected by a revised requirement. A vendor claiming complete nationwide AHJ coverage should provide its actual coverage definition, update frequency, exclusions, and evidence rather than an impressive map alone.

Can the system preserve the exact submission and its receipt?

A file folder with a PDF labeled "final" is not proof that the AHJ received it. The application record should identify the packet that was transmitted, the portal or channel used, the time submitted, the applicant, the official reference number, and the acknowledgment or receipt. When the packet is revised, the system should retain which version belonged to each submission event instead of silently replacing the original.

This buyer criterion is deliberately narrower than a general document-management strategy. You are not evaluating every contract and photo in the company. You are testing whether the permit tracker can reconstruct one application history. Select a completed permit, then ask the vendor to demonstrate how an unfamiliar coordinator would determine what was sent first, what changed, when it was sent again, and what the authority ultimately approved.

How should corrections change the workflow?

A correction notice should not merely change a status badge to red. It should become a controlled work item with the authority's exact comment, responsible discipline, required response, target date, associated drawings, and a clear path back to the reviewer. One notice can contain multiple comments, and different owners may need to respond. The permit record should make it possible to see whether all required responses are complete before the resubmission is marked ready.

Do not assume every correction requires a full redesign. Some are administrative, others involve electrical or structural judgment, and some expose an equipment or scope conflict. During evaluation, test both a missing signature and a substantive plan revision. The system should route each to the appropriate person, preserve the original reviewer comment, and avoid declaring the application "submitted" again until there is evidence that the revised package actually went out.

What should the permit queue show a manager?

A permit queue should help a manager intervene before the weekly meeting. Useful filters include no AHJ response since last check, unassigned next action, open correction older than policy, submitted without receipt, approval received but install not released, and applications requiring customer information. Grouping by AHJ and coordinator can expose concentration of work, but it should not become a scoreboard that punishes employees for external review times.

Ask for a live drill-down from a queue item into the evidence and next action. If the dashboard reports 11 overdue permits, can the manager identify which three need a call today and which eight are simply in an AHJ review window? Can the manager reassign the follow-up without losing the original owner's history? This is more valuable than a single average permitting duration with no explanation of where time was spent.

How do you measure permit aging without misleading the team?

Track several clocks rather than one vague "days in permitting" number. Calendar days since first submission describe customer waiting time. Business days in the current state may help manage a reviewer-follow-up policy. Days awaiting internal correction expose work the installer controls. Days awaiting AHJ response describe external time. If a permit moves back and forth, a single average conceals the actual cause.

Define the start and stop events before comparing vendors or employees. Does the clock begin when a packet is ready, when it is submitted, or when the AHJ accepts it as complete? Does a correction pause the external-review clock? Different answers can all be defensible, but mixing them creates false comparisons. A credible tool stores the underlying events so your reporting rules can be changed without rewriting history.

Which integrations actually matter?

A vendor may advertise dozens of integrations, but a permit team benefits from a few reliable connections to business records. It should be able to inherit accurate site and sold-scope data, associate the current design release with an application, surface permit approval to project scheduling, and retain permit-related costs against the correct job. Customer communication and finance should receive appropriate milestone updates without treating an unverified status as approval.

Specialist design tools, engineering services, local permit portals, and SolarAPP+ may remain separate when their capabilities are appropriate. That is not a reason to fragment the installer’s customer, project, workforce, purchasing, and financial records. Ask whether integrations preserve source identity and timestamps, handle failures visibly, and allow manual recovery. "Connected" means that a wrong or late message can be detected and corrected, not merely that two logos appear on a slide.

How is SolarAPP+ different from a permit tracker?

SolarAPP+ is an automated permitting platform used by participating AHJs for eligible rooftop solar and solar-plus-storage projects. The Department of Energy explains that eligible submissions can undergo automated code checks and receive rapid approval, while more complex projects can be directed to manual review. Availability and eligibility depend on the jurisdiction and project characteristics.

A commercial permit tracker solves a different problem: managing an installer's full portfolio of applications and follow-ups across varying authorities and processes. A company may use SolarAPP+ for eligible submissions and still need a company-wide record of other permits, inspections, interconnection, responsibilities, and customer commitments. During a demo, ask exactly what the vendor automates, what the AHJ itself performs, and which steps remain the contractor's responsibility.

Should you buy standalone permit software or a broader solar ERP?

A standalone permitting tool may be appropriate when the company has a narrow bottleneck, a small team, and dependable connections to its existing business records. A specialist service may also bring jurisdiction knowledge or permit preparation capacity that an ERP should not pretend to replace. The buyer should value those strengths instead of demanding that every platform perform every specialist task.

A complete solar-specific ERP becomes more relevant when permitting affects procurement, crew readiness, milestone billing, project profitability, customer updates, and management reporting. The decision is about where the business record should live. You may still use external specialist services, but you should not need to re-create the same project and customer across five systems to know whether an approved permit makes the job ready to schedule.

Compare the choices against the work, not the feature list.

Use a structured scorecard during demos. Score each category from zero (not demonstrated) to four (demonstrated on your project with evidence). Multiply the score by its weight, then divide by four to obtain the weighted points. Treat a vendor's slide or verbal assurance as "not demonstrated" until the workflow is shown. Adjust weights for your project mix before testing, not after you have a preferred vendor.

A residential installer with many AHJs may give more weight to jurisdiction coverage and follow-up management. A commercial EPC with complex design changes may prioritize multi-permit records, approvals, dependencies, and traceability. An owner trying to reduce software sprawl may assign more weight to finance and project integration. A weighted score does not replace reference checks, contract review, data security review, or a realistic implementation plan.

What should the vendor demonstrate with your own projects?

Bring three sanitized examples: one straightforward residential permit, one project with multiple corrections, and one application in a jurisdiction with unusual forms or manual communication. Provide the documents and event dates, then ask the vendor to reconstruct the complete permit history. The test should include one missing receipt, one late AHJ response, and one approved permit that should release an installation planning task.

Do not allow the presenter to skip the awkward steps by saying they are configurable. Ask the actual user to enter a correction, assign it to design, attach the revised packet, log the resubmission, and show the resulting queue. Then have another person locate the current permit state without coaching. A platform that works only when the original coordinator explains the history has not passed the handoff test.

What security and data-ownership questions belong in the evaluation?

Permitting records may contain customer names, addresses, electrical drawings, signatures, and project details. Buyers should review role-based access, audit history, file retention, backups, export formats, deletion policy, and what happens when a user leaves. Ask whether a subcontractor can see only the projects assigned to them and whether sensitive attachments can be restricted separately from status information.

Export is a particularly useful test. Request a sample export of applications, status history, tasks, comments, document links, and timestamps. If the vendor cannot provide an intelligible record without a paid professional-services project, migration and future audit work may be harder than the sales presentation suggests. Security certifications and contractual protections should be verified directly; do not infer them from a polished interface.

What will permit tracking software cost beyond the subscription?

Total cost includes seats or project-based fees, onboarding, data cleanup, configuration, training, integrations, support, and the ongoing effort to maintain AHJ knowledge. Some vendors bundle permit preparation services; others sell only workflow software. Compare like with like. A cheap tracking subscription is not comparable to a managed service that also prepares packets, and neither price tells you whether the company-wide project record will remain coherent.

Ask for the price at today's volume and at twice that volume. Confirm whether inactive projects count, whether external collaborators need paid seats, whether document storage is capped, and whether API access or support costs extra. Request the cancellation and data-export terms before signing. The cheapest first-year quote can be the most expensive option if the team must rebuild its permit history or maintain a parallel spreadsheet.

How can you calculate the administrative value without inventing savings?

Start with work you can observe. Suppose a permit team processes 40 applications a month and spends an average of 12 minutes per application checking inboxes, copying the latest status, and identifying the next owner. That is 480 minutes, or eight staff hours per month. At an illustrative fully loaded labor cost of $45 an hour, the current activity costs $360 monthly. These are sample assumptions, not an industry average.

If a tested workflow reduces the activity to five minutes, the arithmetic becomes 40 × 5 ÷ 60 = 3.33 hours, or about $150 monthly. The illustrative difference is 4.67 hours and about $210 per month, before software fees, onboarding, exceptions, or any other costs. That is not a forecast of Solar1 results. Time the actual steps in your own team, including failed automations and correction handling, before claiming a return.

Why can schedule value matter more than clerical time?

A delayed approval may affect crew allocation, equipment storage, customer expectations, financing conditions, and contract-specific billing milestones. But it is unsafe to attach a universal dollar value to every day in permitting. A project with materials already allocated and a fixed crew date faces different exposure from one whose installation window is months away. Approval also does not necessarily authorize every subsequent activity.

Build a local scenario instead. Identify the jobs where a permit event actually controls the next schedule decision. Record the rescheduling effort, idle labor if any, storage or carrying cost if measurable, and the relevant billing condition. Count only costs the workflow could realistically influence. The purpose of a tracker is to make an earlier, better-informed decision possible; it cannot make an AHJ approve a project or guarantee a shorter review.

Which KPIs tell you whether the purchase is working?

Choose a short measurement set: applications without a verified next action, median internal correction turnaround, submitted applications lacking acknowledgment, follow-ups missed against policy, time from permit approval to scheduling release, and percentage of permit records with complete evidence. Track AHJ review duration separately from installer-controlled work so the team is not credited or blamed for a regulator's backlog.

Measure a baseline for several weeks before rollout. Compare the same project types and jurisdictions where possible. A shift toward more storage projects, more commercial work, or a new service territory can change averages even when the team is doing better. Report counts and distributions alongside medians. A reduction in "unknown status" records may be the earliest useful outcome, even before a meaningful change in overall project cycle time appears.

What red flags should stop a software purchase?

Be cautious when a vendor cannot distinguish expected and verified dates, has no evidence trail for a status change, shows one permit per project with no exception path, promises universal AHJ automation without jurisdiction-specific proof, or requires an administrator to edit hidden configuration for every correction. A missing export path and an inability to show a realistic correction cycle are also serious warning signs.

Other concerns are subtler: a queue that cannot be filtered by next action, reminders with no accountable owner, a customer portal that repeats stale internal statuses, or "approved" events that automatically trigger downstream work without validation. Ask what happens when the integration is down or the AHJ portal changes. If the vendor's answer depends on a perfect data feed, you are buying an optimistic diagram rather than a dependable operating process.

How should an installer roll out a permit tracker?

Begin with one market or one project type and a small set of active permits. Define the official source for each status, the internal owner, the follow-up policy, and the required evidence. Import only the records needed for a meaningful pilot. Have the coordinators operate the new system alongside the existing process briefly, then reconcile every mismatch rather than assuming the new screen is automatically correct.

Set a clear cutover rule: the tracker becomes authoritative only when the team can reproduce the live queue, identify missing receipts, manage corrections, and export a reliable history. Train scheduling and finance on what an approved permit means and, just as importantly, what it does not mean. Review the pilot with real projects before expanding to more jurisdictions. That keeps configuration work tied to observable problems.

Where does Solar1 fit in this buying decision?

Solar1 is being built as a complete solar-specific ERP for installers and EPC companies, with permitting as one part of a connected business. Its product direction includes carrying customer and site information through survey, design, permits, interconnection, purchasing, field scheduling, job cost, billing, service, and reporting. In that model, a verified permit event belongs to the same business record as the work it may release.

That direction is different from selling an isolated permit dashboard or a connector between unrelated CRMs and accounting tools. Specialist services may still support design, engineering, or jurisdiction submissions where appropriate. Solar1 is under development, and the descriptions in this guide are evaluation criteria and intended product direction, not a claim that every permit workflow, portal connection, automation, or reporting feature is live today.

What is the next step before signing?

Write down five current permit problems using actual project records, not general complaints. For each, identify the missing information, who needed it, and the decision that was delayed. Use the scorecard above to test two or three candidate workflows on the same examples. Compare the evidence each vendor can produce, the administrative work still required, and the consequences for scheduling and finance.

If you are considering a broader operating system, read our solar project lifecycle guide to map the downstream decisions, and our solar document management guide to assess document revision controls. Then book a Solar1 workflow discussion with your current permit queue and ask which parts of the intended ERP workflow can be demonstrated today.