Spreadsheets do not fail all at once. They fail one handoff at a time.

A permit date gets missed.

A design revision never reaches procurement.

A crew arrives before the materials or customer are ready.

Finance learns about the problem when the invoice or margin report is already late.

When should a solar installer move from spreadsheets to ERP?

A solar installer should move from spreadsheets to ERP when the cost and risk of coordinating work manually become greater than the simplicity of the spreadsheet. There is no universal employee count, revenue level, or project volume that creates the answer. A five-person commercial EPC with highly variable projects may reach the limit before a larger residential installer repeating a standard process. The practical trigger is operational complexity: several people updating the same projects, frequent handoffs, changing designs, permit and interconnection dependencies, material commitments, crew scheduling, milestone billing, project labor, and service obligations that must remain connected.

A useful rule is to look for repeated symptoms rather than one dramatic failure. If three or more of the warning signs in this guide happen every week, the company should begin an ERP evaluation. If six or more are affecting schedules, cash, inventory, customer communication, or job cost, the migration has become an operating priority. This scoring model is a decision framework, not an industry benchmark. Its purpose is to turn a vague feeling that the spreadsheets are getting messy into a concrete management discussion.

Why do spreadsheets work so well in the beginning?

Spreadsheets are flexible, familiar, inexpensive, and fast to change. A founder can create a lead tracker in the morning, add permit stages after lunch, and build a cash forecast before the end of the day. That flexibility is valuable while the company is learning its process. A small team can also compensate for missing controls through direct communication. The sales lead knows which project was sold, the project manager remembers the permit correction, and the owner understands the cash position because they are involved in nearly every decision.

The problem begins when business knowledge stops fitting inside a few people’s heads. More projects create more combinations of customer requirements, system designs, AHJs, utilities, equipment, financing terms, crews, inspections, and payment milestones. The spreadsheet may still open and calculate correctly, but the operating process around it becomes slower. Staff start maintaining private trackers, sending screenshots, copying rows between files, and asking in meetings which status is current. The file is not necessarily broken. The company has simply asked it to provide workflow control, accountability, document history, access permissions, and cross-department coordination that it was never designed to own.

Why does this matter more in solar operations?

Solar installation is unusually dependent on connected administrative work. The U.S. Department of Energy includes design, siting, permitting, installation, interconnection, financing, customer acquisition, workforce activity, supply-chain and inventory control, and operating overhead within solar soft costs. DOE also says soft costs account for about two-thirds of the overall cost of residential systems. That does not mean an ERP removes two-thirds of system cost. It means the non-hardware process surrounding an installation is economically important, and inefficient handoffs can consume real margin even when module and inverter pricing is well controlled.

The market is also operating at substantial scale. SEIA reported that the United States exceeded six million cumulative solar installations in the first quarter of 2026 and added 7.8 GW of new solar capacity during that quarter. Growth does not automatically require every installer to buy an ERP, but it increases the value of repeatable execution. As the company handles more customers, jurisdictions, crews, equipment options, batteries, service requests, and financing arrangements, spreadsheet flexibility can turn into uncontrolled variation. The question is not whether Excel or Google Sheets can store more rows. The question is whether the business can still trust the process represented by those rows.

10 signs your solar company has outgrown spreadsheets

1. More than one team maintains the same project status

Sales has one pipeline, operations has a project tracker, permitting has a submission sheet, and finance has a billing file. Each version may be reasonable for its owner, but none shows the complete job. When a project changes, someone must remember every place that needs an update. Conflicting statuses are a stronger ERP signal than the number of spreadsheet rows. A project cannot be ready to install in operations while procurement shows missing equipment and finance shows an unpaid deposit. When multiple teams must reconcile their files before management can understand the job, the company has moved beyond a simple tracking problem.

2. Status meetings exist mainly to rebuild the truth

A healthy operations meeting makes decisions. An unhealthy one spends most of its time asking for updates that should already be visible: Has the survey been completed? Which design is approved? Did the AHJ send comments? Is the battery in stock? Did the crew upload completion photos? Can the next invoice be issued? When the meeting is the integration between systems, leadership is paying skilled employees to perform manual data synchronization. The warning sign is not that meetings exist. It is that the company cannot prepare an accurate portfolio view without calling several people and comparing several files.

3. The sales-to-project handoff requires retyping the sold scope

After a contract is signed, operations should receive a controlled record of what was sold. If project coordinators recreate the customer, address, equipment, system size, payment terms, adders, exclusions, financing assumptions, and promised dates from a proposal or sales note, the company has created a high-risk handoff. Small differences become expensive later. The wrong module count affects design and purchasing. A missed electrical upgrade affects scheduling. An unclear payment milestone affects cash. Moving to ERP becomes justified when the signed commercial scope cannot become the operational project without manual reconstruction.

4. Design revisions do not automatically reach every affected team

Solar projects change. A module substitution, battery addition, service-panel issue, structural constraint, customer request, or AHJ correction can affect the plan set, bill of materials, permit package, purchase order, crew instructions, project budget, and customer expectation. In a spreadsheet-driven process, revision control often depends on filenames, chat messages, and individual memory. If procurement can order from an old equipment list or a crew can receive an outdated drawing, the spreadsheet is no longer providing enough control. The ERP should not replace specialist design calculations, but it should own the request, version, approval, downstream impact, and current project record.

5. Permit, inspection, and PTO follow-ups depend on memory

A spreadsheet can list a submission date, but it does not automatically create ownership, reminders, escalations, document completeness, correction history, or a reliable days-in-stage view. The risk increases when each AHJ and utility has different forms, contacts, review patterns, and inspection requirements. NREL’s review of SolarAPP+ reported that 668 installers submitted 18,906 permits through the platform in 2023, and that a typical SolarAPP+ project was permitted and inspected 14.5 business days sooner than projects using traditional processes. Those results are not ERP performance claims. They demonstrate the operational value of structured information and repeatable workflows compared with manual processing.

6. Inventory is tracked separately from project demand

A warehouse sheet may show that ten inverters are available, while the project tracker shows eight installations scheduled. Neither file may show that six inverters are already allocated, two are awaiting inspection replacement, and one incoming shipment is delayed. Inventory becomes an ERP issue when purchasing, warehouses, project allocation, serial numbers, material issuance, substitutions, returns, and warranty records must agree. The most important question is not how much stock the company has. It is which approved material is available for which project, at which location, and by which date. If the answer requires several calls and files, installation readiness is being estimated rather than controlled.

7. Crews are scheduled before the job is truly ready

A calendar date is not the same as an installation-ready project. Readiness may depend on approved drawings, permits, utility conditions, customer access, deposit status, roof or electrical prerequisites, allocated materials, qualified crew capacity, vehicle availability, and weather. Spreadsheets often track these items in different tabs or not at all. The result is an optimistic schedule that looks full until the morning dispatch changes. If coordinators repeatedly move jobs because one dependency was missed, the company needs a readiness workflow that brings every condition into one decision rather than another scheduling sheet.

8. Field updates do not change the office or financial record

Crews may send photos in chat, submit hours in a separate form, report material shortages by phone, and mark completion in a field checklist. If those updates do not change project progress, inventory, labor cost, inspection readiness, billing milestones, and customer communication, the company still has to translate field activity manually. A mobile application alone does not solve this. The signal for ERP is that field information must trigger actions across the business. Installed quantities should reduce allocated inventory. Man-hours should reach project labor cost. Completion evidence should advance inspection and billing. A blocker should create an owner and prevent the project from appearing complete.

9. Job cost and margin are calculated after the project is finished

A project can look operationally successful while losing margin through design rework, permit corrections, expedited freight, unused crew time, substitutions, overtime, repeat visits, or delayed billing. When costs live in purchasing software, payroll files, expense reports, inventory sheets, and accounting entries, the true project result appears late. ERP becomes important when owners and finance leaders need committed cost, actual cost, labor cost, invoiced revenue, collected cash, and forecast margin while the job is still active. The purpose is not simply a cleaner report. It is to give the team time to act before a preventable cost becomes a closed-project explanation.

10. Customer, warranty, and service history disappear after PTO

Spreadsheet processes often focus on getting the project installed, inspected, and paid. Later, a service coordinator may need to reconstruct what was sold, which serial numbers were installed, which design was approved, what warranty applies, whether a part was replaced, and what a previous technician found. If service history starts in a new file or ticketing tool without the installation record, the business loses lifecycle continuity. Installers planning to offer O&M, warranty support, battery service, upgrades, or long-term customer care should treat the project as an asset record that continues after PTO, not as a completed row moved to an archive tab.

Is there a project-volume threshold for moving to ERP?

Project count is useful, but it should not be treated as a universal rule. The Solar1 content plan uses 30 active projects as an illustrative breaking-point visual because it is easy to understand, not because the thirtieth project creates a scientific threshold. Thirty standardized residential jobs managed by one experienced team may be simpler than eight commercial projects across several jurisdictions, subcontractors, engineering reviews, warehouses, billing schedules, and utility processes. The better measurement is concurrent complexity: how many active jobs require decisions, how many teams touch each one, and how often the job changes from the standard path.

Use a simple illustrative calculation. Suppose 30 active projects each create ten minutes of status chasing per working day across project managers, permit staff, procurement, field leadership, and finance. That equals five administrative hours per day, or 1,250 hours across 250 working days. At an illustrative loaded labor cost of $45 per hour, the annual coordination cost is $56,250 before counting delayed invoices, wasted truck rolls, incorrect orders, rework, or lost customer trust. This is not an industry benchmark or a promised ERP saving. It is a way to calculate whether manual coordination is already costing more than the company realizes.

Use this 10-point spreadsheet-to-ERP readiness score

Give the company one point for each statement that is true most weeks:

1. Two or more teams maintain separate versions of project status.
2. Management reporting requires manual exports, reconciliation, or status meetings.
3. Signed project information is retyped during sales-to-operations handoff.
4. Design revisions can reach permitting, purchasing, or crews late.
5. Permit, inspection, interconnection, or PTO follow-ups depend on memory.
6. Inventory availability is not linked to approved project demand.
7. Crews are rescheduled because readiness was not checked in one place.
8. Field time, materials, photos, and completion do not update the central project record.
9. Actual job cost or margin becomes clear only after closeout.
10. Service and warranty teams cannot see the complete installation history.

How to interpret the score

A score of 0 to 2 means spreadsheets may still be appropriate, provided the company uses controlled templates, clear ownership, backups, and a documented process. A score of 3 to 5 means the business should map workflows and pilot an ERP around the highest-cost handoffs. A score of 6 to 8 indicates that disconnected operations are likely affecting cost, schedule, cash, or customer experience, so migration should become a planned management initiative. A score of 9 or 10 suggests the company is already using people and meetings as the operating system. Do not buy software based on the score alone. Use it to identify where the business case must be proven.

What should a solar installer move into ERP first?

Do not begin by importing every historical spreadsheet. Begin with the records and handoffs that determine whether a current project moves forward correctly. The first phase should establish one customer and project identity, controlled lifecycle stages, responsibility, required documents, and the current sold scope. From there, add the workflows where delay or error is most expensive. The exact order depends on the installer, but a practical sequence is:

1. Customer, site, contract, project, sold scope, and responsible owner.
2. Project stages, tasks, approvals, required documents, and exception reasons.
3. Survey, design revision, engineering, permitting, interconnection, inspection, and PTO control.
4. Procurement, purchase commitments, inventory allocation, serial numbers, and installation readiness.
5. Crew scheduling, mobile field updates, man-hours, materials used, issues, photos, and completion evidence.
6. Milestone billing, receivables, payables, expenses, payroll impact, job cost, cash, margin, service, and warranty.

What should remain in spreadsheets after ERP?

Moving to ERP does not require banning spreadsheets. They remain useful for temporary analysis, scenario modeling, one-time imports, data cleanup, private calculations, early prototypes, and reports that do not control the live business. A finance leader may model a hiring plan in a spreadsheet. Procurement may compare a one-time supplier scenario. An analyst may explore historical data before deciding whether the report belongs in the ERP. The boundary is ownership. A spreadsheet should not remain the only place where the current project stage, approved design, material allocation, crew assignment, invoice eligibility, payment status, or warranty history exists.

How can a solar installer migrate without disrupting operations?

The safest migration is phased around complete workflows, not isolated departments. A big-bang switch can overload the team, while a module-by-module rollout can create new gaps if each module is launched without its upstream and downstream handoffs. Start with one representative project type and follow it from signed contract through the next meaningful business outcome. For many installers, that means contract to installation-ready, installation-ready to completion, or completion to invoice and PTO. Use a limited group of real users, resolve missing fields and ownership problems, then expand the workflow to more projects and teams.

Phase 1: Map the current process and remove duplicate truth

Choose several recent projects, including at least one normal job and one difficult job. Map every spreadsheet, form, folder, chat group, email, and specialist tool used from lead through service. Mark where information is retyped, where approval is informal, where a status can conflict, and where finance waits for operations. Then define which system should own each core record. This step often reveals that the company does not have a software problem alone. It has undefined stages, inconsistent naming, missing ownership, and exceptions that have never been documented.

Phase 2: Build the project foundation

Create clean customer, site, contract, project, equipment, stage, and user records. Define mandatory fields, role permissions, approval points, document requirements, and the reasons a project can be blocked. Import only data that is accurate and useful for current operations. Historical files can be retained as an archive when cleaning them would cost more than their operational value. The objective is not to reproduce every spreadsheet column. It is to create the minimum trusted record needed for teams to run the next project without rebuilding information.

Phase 3: Connect operational and financial triggers

Once project stages are stable, connect procurement, inventory, field activity, employee time, expenses, billing, and job cost. Define what evidence is required before a purchase is approved, a project is marked ready, a crew is dispatched, an installation is completed, an invoice is issued, or a warranty case is opened. Test exceptions deliberately. Change the design, delay an item, fail an inspection, add overtime, replace equipment, and postpone a customer payment. A useful ERP should show who owns the next action and which schedule, cost, cash, or customer commitments are affected.

Phase 4: Retire the parallel trackers

A migration is incomplete while teams maintain the old spreadsheet just in case. Set a clear cutover date for each workflow, provide role-based training, and monitor whether users are creating new side files. Parallel tracking may be necessary during a short validation period, but it should have an owner and an end date. When a spreadsheet remains useful for analysis, label it as a report rather than an operating record. Management must also use the ERP in meetings and decisions. Staff will not trust the new system if leaders continue asking for the old file.

What are the most common spreadsheet-to-ERP migration mistakes?

• Buying software before mapping the real workflow.
• Trying to reproduce every spreadsheet, including years of accidental complexity.
• Importing duplicate customers, outdated statuses, and unverified material data.
• Launching modules without connecting the handoffs between sales, operations, field, and finance.
• Treating training as a single demonstration instead of role-based adoption.
• Keeping old spreadsheets as an unofficial second source of truth.

The biggest mistake is assuming ERP will repair an undefined process automatically. Software can enforce stages, permissions, required fields, approvals, and triggers, but the company must decide what those controls should mean. A vague process inside a more powerful system is still vague. The implementation should simplify before it automates: remove duplicate fields, standardize project stages, define readiness, assign ownership, and agree on the conditions that move work forward.

How is Solar1 approaching the move from spreadsheets to ERP?

Solar1 is being built as a complete solar-specific ERP for installation companies and EPCs. The product direction covers the connected business lifecycle: CRM, surveys, design workflow, proposals, projects, engineering, permitting, interconnection, procurement, inventory, field operations, HR, payroll, fleet, accounting, customer communication, service, warranty, analytics, permissions, and administration. The purpose is not to replace one project spreadsheet with another isolated tracker. It is to keep the customer, project, employee, material, operational, service, and financial records connected from lead through cash, PTO, and long-term support.

Solar1 is still under development, so this guide describes the capability and migration model a complete solar ERP should support rather than claiming that every mapped module is currently production-ready. The intended implementation approach is phased. Installers should begin with the workflows creating the greatest operational cost, establish a trusted project foundation, and add connected capabilities without forcing every team into a risky overnight switch. Specialist design engines, financing providers, payment services, banking, communications, telematics, and monitoring tools may still integrate where they provide focused depth.

The real breaking point is not the size of the spreadsheet

The breaking point arrives when people must remember how to connect the business. Count the weekly status-chasing hours. Count the records entered more than once. Count the schedule changes caused by missing readiness information, invoices waiting for operational confirmation, and projects whose margin becomes visible too late. Then score the ten warning signs. That evidence will tell you whether the next step is a cleaner spreadsheet, a limited workflow pilot, or a complete ERP migration. Solar installers preparing for that decision can use a spreadsheet-to-ERP migration checklist to map the first workflow before evaluating software.