Most bad software purchases do not fail in the demo. They fail six months later, when the messy project arrives.

A polished dashboard proves almost nothing.

Every vendor can show the happy path.

The real test is a permit correction, a late inverter, a crew change, and an invoice that depends on evidence from the field.

These 75 questions are built for that test.

What belongs in a solar ERP requirements checklist?

A useful solar ERP requirements checklist must test the entire operating lifecycle, not only CRM screens or project boards. It should cover sales, surveys, design control, engineering, permitting, interconnection, procurement, inventory, field work, employees, payroll, finance, customer communication, service, reporting, security, data ownership, implementation, and vendor support. More importantly, it should ask how one change moves through those workflows. The right question is rarely “Do you have inventory?” It is “When an approved design changes, can the system update project demand, purchasing, allocation, cost, crew instructions, and the current plan set without someone rebuilding the truth in a spreadsheet?”

This matters because solar’s non-hardware work is operationally expensive. The U.S. Department of Energy includes design, permitting, interconnection, customer acquisition, workforce activity, supply chain, inventory control, and operating overhead within solar soft costs. A buyer who evaluates those activities as separate feature boxes can miss the handoffs where schedule, margin, and cash are actually lost.

Why 75 questions instead of another feature list?

Feature lists are easy to agree with and hard to use. A vendor says “yes” to project management, inventory, dashboards, mobile access, and integrations. The buying team checks the boxes. After go-live, it discovers that the project board cannot enforce readiness, inventory is not allocated to the approved bill of materials, field photos do not trigger billing, and the integration moves only customer names. The feature technically exists, but the operating requirement does not.

Use these questions in requirements workshops, demos, reference calls, contract review, and user acceptance testing. Mark irrelevant items honestly, but do not remove difficult questions simply because a vendor says they are “handled during implementation.” That is where hidden scope often begins.

Use the five-answer rule before you score any vendor

Do not accept a bare yes or no. Require every answer to be placed in one of five categories and backed by proof. The categories prevent a roadmap promise from receiving the same score as a workflow that is live today.

The scores are an evaluation framework, not an industry standard. Before scoring, label each requirement as critical, important, useful, or not relevant. A vendor should not win by collecting points on low-value features while failing one critical requirement such as job cost, data export, permit ownership, material readiness, or role-based access. A zero on a critical requirement should trigger a decision, not an average.

How should a solar company use this checklist?

Build the checklist with the people who do the work. Sales should define sold scope, permitting should define corrections, field leaders should define readiness, and finance should define invoice and cost triggers. Then bring one normal job and one difficult job into every serious demo.

The 75 solar ERP requirements questions

1. Business fit and operating model

Start with the shape of the company. Software that handles one simple residential workflow may look excellent in a demo and still be the wrong foundation for multiple branches, C&I work, service obligations, or country-specific finance. These first questions establish whether the platform can represent the business before it tries to automate it.

1. Can the platform support your actual mix of residential, commercial, community-solar, and EPC projects? Ask the vendor to show how project types differ without splitting the company into disconnected systems.

2. Can workflows vary by branch, market, project type, AHJ, or utility while still rolling into one portfolio view? Local variation is normal. Unreportable variation is not.

3. Can one customer record support multiple contacts, sites, projects, systems, assets, and service histories? Commercial and repeat customers quickly expose weak record structures.

4. Can the system handle the entities, currencies, tax rules, languages, and regional controls your company genuinely needs? U.S. and European requirements should be evaluated country by country, not assumed from a generic “global” label.

5. Will the vendor demonstrate one complete project from lead through cash, PTO, warranty, and service? Separate module tours hide broken handoffs.

2. CRM, sales, proposals, and contracts

The project inherits whatever sales captured, promised, priced, and approved. A weak sales-to-project structure creates downstream work even when the CRM itself feels easy to use.

6. How are duplicate leads, territories, lead sources, assignments, and ownership handled? The first source-of-truth problem often starts before the opportunity is qualified.

7. Can sales activities, appointments, site visits, follow-ups, notes, documents, and customer communication stay on the same record? Reps should not need private calendars and message threads to reconstruct the relationship.

8. Can pipeline stages require specific data, approvals, or next actions before an opportunity advances? A stage name without entry and exit rules is only a label.

9. Can proposals manage equipment options, adders, exclusions, production assumptions, pricing, financing scenarios, incentives, and approval history? The operational team needs to know exactly what the customer accepted.

10. Are contracts, signatures, revisions, expiration dates, deposits, and customer approvals version-controlled? A signed PDF should not become an unstructured dead end.

11. When a deal closes, does the approved sold scope create the project without retyping customer, site, equipment, price, and commitment data? Manual reconstruction is where sales promises turn into project risk.

3. Site survey, design workflow, and engineering

A complete ERP does not need to replace every specialist calculation. It does need to control the request, version, approval, equipment, documents, and downstream consequences of design and engineering work.

12. Can field staff capture structured survey data, measurements, photos, GPS details, roof and electrical conditions, and customer access notes on mobile? A photo folder is not a complete survey record.

13. Can required evidence and completeness rules stop an incomplete survey from reaching design? The system should prevent avoidable questions, not merely record them later.

14. Can design requests, assignments, priorities, due dates, service levels, and workload be managed against the project? Design capacity should be visible before it becomes a sales or permit delay.

15. Can the platform track design versions, comments, approvals, rejected options, and the current approved configuration? The team must know which version is authoritative and why it changed.

16. If a specialist design or engineering tool is used, what data returns to the ERP and which system owns the approved result? An integration should not create two competing versions of equipment, production, or project scope.

17. Can plan sets, redlines, drawing packages, engineering reviews, approval gates, and approved-for-construction documents be controlled? A crew receiving an old plan set is not a minor document problem.

4. Project management and cross-team handoffs

Generic task management is not enough. Solar projects need controlled transitions between sold scope, survey, engineering, permits, utility work, materials, field execution, finance, and closeout.

18. Is there a controlled sales-to-project readiness gate before engineering, permitting, procurement, or scheduling begins? Operations should not inherit incomplete sold jobs.

19. Can stages have entry criteria, exit criteria, dependencies, required documents, and automatic next actions? A board should control work, not only display cards.

20. Can every blocker have a reason, owner, due date, escalation path, and effect on forecast dates? “On hold” is not useful unless the next action is clear.

21. Can templates vary by project type while preserving common reporting and governance? Residential repeatability and commercial complexity should not force separate operating systems.

22. Are documents, decisions, comments, approvals, customer updates, and audit history attached to the project lifecycle? The project record should explain what happened without relying on memory.

23. Can managers see portfolio capacity, aging, exceptions, forecast milestones, and projects at risk without rebuilding reports? Management visibility should exist before the weekly meeting.

5. Permitting and AHJ requirements

The latest SolarAPP+ performance review, published in 2026 using 2024 data, reported 37,393 permits submitted by 861 installers. It found a typical SolarAPP+ project was permitted and inspected 12 business days sooner than traditional projects. Those are not ERP performance claims. They show why structured specifications, completeness checks, and repeatable permitting records deserve serious buyer questions.

24. Can the system store AHJ contacts, requirements, forms, fees, review rules, inspection needs, and local notes? Permitting is jurisdiction-specific, and generic task names are rarely enough.

25. Can a permit packet be checked for required documents and data before submission? The 2026 SolarAPP+ performance review shows the value of structured specifications, automated review, and inspection checklists.

26. Can submission dates, fees, permit numbers, responsible owners, due dates, and days in stage be tracked together? A date column alone does not create accountability.

27. Can correction letters, comments, revised documents, resubmissions, approvals, and their full history be managed? The second submission should not overwrite the first.

28. Can a project support multiple permits, inspections, failed inspections, reinspections, and jurisdiction-specific outcomes? Real projects rarely follow a single clean approval event.

29. Will the vendor demonstrate an AHJ correction that changes design, documents, schedule, customer communication, and cost? This messy test reveals whether permitting is connected or merely tracked.

6. Utility interconnection and PTO

Interconnection is often tracked as a vague final stage even though it contains its own applications, documents, approvals, waiting periods, meter work, and financial effects. Treat it as a controlled workflow.

30. Can utility-specific requirements, forms, contacts, fees, portal references, and submission rules be maintained? Interconnection should not be reduced to one status field.

31. Can the workflow track application, study, agreement, utility inspection, meter activity, energization, PTO, and COD where relevant? The required stages vary by project and market.

32. Can permit and interconnection statuses remain distinct while still affecting the same project forecast? Combining them hides ownership. Separating them completely hides their relationship.

33. Can document readiness, submission history, aging, next action, owner, and escalation be seen for every application? Teams need to know why the utility process is waiting.

34. Can PTO trigger the correct billing, closeout, customer notification, asset activation, service, and warranty actions? PTO is an operational and financial milestone, not only a project note.

7. Procurement, suppliers, and inventory

Inventory questions should begin with project demand and end with installation readiness. Counting parts is only one part of the job.

35. Can the approved design or bill of materials create project demand without manual re-entry? Procurement should buy from the current approved scope.

36. Can buyers compare quotations, suppliers, lead times, terms, substitutions, and landed cost before issuing a purchase order? The cheapest line item may not protect schedule or margin.

37. Can purchase requests, approvals, purchase orders, committed cost, partial deliveries, and expected dates be tied to the project? Committed cost matters before the invoice arrives.

38. Can inventory be tracked by warehouse, location, project allocation, transfer, material issue, return, and available-to-promise quantity? Stock on hand is not the same as stock available for Thursday’s job.

39. Can equipment substitutions require technical and commercial approval and update downstream records? A substituted inverter can affect design, permit documents, cost, crew instructions, and warranty.

40. Can serial numbers, batches, damaged items, warranty data, and material readiness block or release installation scheduling? Installation readiness should be evidence-based.

8. Field operations, HR, payroll, and fleet

Field operations are where the planned project meets the actual site. The system should return structured evidence, cost, progress, and exceptions, not only photos and completed tasks.

41. Can crews see the current scope, drawings, equipment, customer instructions, safety requirements, and checklist on mobile? The field should not search chat threads for the latest document.

42. What happens when crews have weak or no connectivity? Offline or low-signal behavior should be demonstrated, not described vaguely.

43. Can required photos, signatures, timestamps, location data, quantities, and completion evidence be enforced? Field evidence should support inspections, billing, and quality control.

44. Can crews create issues, shortages, safety events, scope changes, and punch-list items with clear ownership? A photo and a caption are not an escalation workflow.

45. Do man-hours, expenses, material usage, repeat visits, and rework update project progress and job cost? Field activity must change the office and financial record.

46. Can employee skills, certifications, shifts, attendance, leave, overtime, expenses, payroll impact, and project labor cost be connected? Crew planning and labor margin depend on more than a user name.

47. Can vehicles, tools, assignments, availability, maintenance, fuel, incidents, and trip cost affect dispatch decisions? A ready project without a qualified crew or available vehicle is not ready.

9. Finance, accounting, job cost, and cash

The strongest financial requirement is not a month-end report. It is the ability to see schedule, commitment, cost, invoice, cash, and margin while the team can still act.

48. Can deposits and milestone invoices be triggered by verified project events and required evidence? Finance should not need to ask operations whether a job can be billed.

49. Can receivables, payables, expenses, purchase commitments, credits, retainage, and payment status be connected to the project? Cash cannot be managed from project revenue alone.

50. Can job cost separate material, labor, subcontractor, permit, freight, equipment, overhead, rework, and service costs? A single total hides where margin moved.

51. Can the company see committed cost, actual cost, forecast cost, revenue, invoiced amount, collected cash, and expected margin while the project is active? Closeout is too late for corrective action.

52. Can cash forecasts use project milestones, purchase timing, payroll, expected collections, and known delays? A sales forecast is not a cash forecast.

53. Can profitability be analyzed by project, customer, branch, salesperson, crew, project type, and time period? Management needs to distinguish growth from profitable growth.

54. Which accounting, finance, payroll, tax, and statutory capabilities are native, configurable, integrated, or country-specific? The vendor should state the boundary clearly instead of saying the platform “connects to finance.”

10. Customer portal, service, warranty, and O&M

A solar customer relationship does not end when the project row is marked complete. The ERP should preserve the installed asset and its commercial, technical, and service history.

55. Can customers securely view milestones, requested documents, approvals, payments, messages, and current status? A portal should reduce status chasing without exposing internal noise.

56. Can customer updates be triggered by verified events and retained in communication history? Automation should not send a cheerful message while the project is blocked.

57. Does the asset record retain the approved design, installed equipment, serial numbers, documents, inspections, payments, and prior service? The installation history should survive project closeout.

58. Can service tickets manage triage, appointments, technicians, parts, warranties, repeat visits, resolutions, and customer communication? Service should not restart the customer record from zero.

59. Can preventive maintenance, O&M schedules, monitoring exceptions, service agreements, and service profitability be tracked? Long-term support requires more than a ticket inbox.

11. Dashboards, reporting, controls, and AI

Dashboards should shorten decisions, not decorate them. Modern evaluation should also include how AI recommendations are sourced, reviewed, corrected, and governed.

60. Can each role see the exceptions, queues, approvals, capacity, and metrics needed to run the day? A CEO dashboard and a permit coordinator’s work queue should not be the same screen.

61. Can every KPI be drilled down to the underlying projects, transactions, definitions, and dates? A number without traceability creates arguments instead of decisions.

62. Can users build, schedule, export, and distribute reports without paying the vendor for every change? Reporting cost often appears after the contract is signed.

63. If AI or automated recommendations are used, can users see the source records, approve consequential actions, correct outputs, and understand how company data is used? AI should not become an unreviewable layer between the team and the record.

12. Security, data ownership, and integrations

Solar ERP may contain customer contracts, addresses, financial data, employee information, system designs, asset history, and operational records. Security and data exit belong in the buying checklist. They are not IT questions to postpone until after selection.

64. Does the contract state that your company owns its data and can export it in a usable, documented format at any time? Data exit should be tested before purchase, not negotiated during a crisis.

65. Are APIs, webhooks, authentication methods, field mappings, rate limits, error handling, monitoring, and integration ownership documented? An integration logo is not an integration specification.

66. Does the platform support appropriate MFA, SSO, role-based access, least privilege, user deactivation, and separation of duties? Access should match job responsibility and change when people move or leave.

67. How are data encrypted, logged, retained, backed up, restored, and protected from unauthorized change or deletion? Ask to see the controls and audit evidence relevant to your risk.

68. What are the backup frequency, recovery process, recovery objectives, incident-notification commitments, and tested disaster-recovery procedures? A backup claim is incomplete without a restore process.

69. Which security assessments, subprocessors, data locations, privacy terms, vulnerability practices, and deletion procedures apply? NIST and CISA guidance both support making supplier security requirements part of software acquisition, not an afterthought.

13. Implementation, support, commercial terms, and vendor proof

A strong product can still become a bad purchase through weak data, undefined scope, poor training, or unclear support. Finish the checklist by testing how the vendor will get the system into daily use and how the relationship can end.

70. What is included in implementation, what is excluded, and what must be true before the first workflow goes live? A vague implementation line item becomes a change-order budget.

71. Who cleans, maps, validates, migrates, reconciles, archives, and signs off customer, project, vendor, inventory, employee, and financial data? Oracle’s implementation guidance emphasizes requirements, data quality, roles, workflows, security, and user acceptance for good reason.

72. Will user acceptance testing include your normal project and your worst realistic exceptions? Happy-path testing produces fragile launches.

73. Is training role-based, performed with your terminology and data, and followed by adoption support after go-live? One generic webinar is not operational readiness.

74. What are the support hours, response targets, escalation path, release process, update notice, maintenance policy, and named ownership? Support quality affects every future workflow failure.

75. What is the complete commercial and exit picture, including subscription, seats, storage, implementation, integrations, custom work, support, renewal terms, data export, and references from similar companies? The buying decision is not complete until cost, proof, and exit are visible.

Do not stop at the questionnaire: run the messy-project test

A written answer is useful. A live test is better. Give every shortlisted vendor the same representative project and ask the team to perform the following events in sequence. Do not let the vendor reset the demo between events. The point is to see whether the project remains one connected record when the happy path breaks.

1. The customer changes equipment after the first design approval.

2. The AHJ issues a correction that requires a drawing and bill-of-materials revision.

3. The preferred inverter is unavailable and procurement proposes a substitute.

4. The installation date arrives, but one required material is not allocated.

5. A qualified crew member is absent and the assigned vehicle is unavailable.

6. The crew completes only part of the scope and reports a site condition.

7. The inspection fails and creates rework, a customer update, and a new visit.

8. PTO is delayed while a final invoice and cash forecast depend on it.

9. Eighteen months later, the customer opens a warranty service request.

10. A user leaves the company and the buyer exports the complete project history.

The vendor should show what changed, who owns the next action, which records were updated, what remained blocked, what reached finance, and what the customer can see. This test is intentionally uncomfortable. Real operations are uncomfortable. The best solar software for your company is the platform that handles your difficult project with the fewest hidden spreadsheets, manual reconciliations, unsupported assumptions, and paid surprises.

What are the biggest red flags in a solar ERP evaluation?

Red flags include a demo that never leaves the prepared sample job, a “yes” answer with no evidence category, an integration claim without field mappings or support ownership, job cost visible only after month-end, inventory disconnected from readiness, dashboards with no drilldown, and contracts vague about data export.

Roadmap honesty matters. A vendor should be able to say that a requirement is planned, unavailable, or outside the product direction. Buyers should also identify requirements they do not need. The goal is not a perfect 75-item score. It is to find the workflows the business cannot afford to rebuild after purchase.

How does this checklist support a search for the best solar software?

Search results for the best solar software are dominated by rankings, comparisons, pricing summaries, and design tools. A requirements checklist fills the missing step. It turns “best” into testable questions about project types, teams, records, exceptions, regional needs, and implementation burden.

For a growing installer, the best solar software is not the platform with the longest feature list. It is the one that can become the trusted system for customer, project, employee, material, operational, service, and financial records, with specialist tools adding depth where appropriate.

How should Solar1 be evaluated against the same questions?

Solar1 is being built as a complete solar-specific ERP for installation companies and EPCs. Its product direction includes CRM, surveys, design workflow, proposals, projects, engineering, permitting, interconnection, procurement, inventory, field operations, HR, payroll, fleet, accounting, customer communication, service, warranty, analytics, permissions, and platform administration. Specialist tools may integrate where they provide focused technical depth, but Solar1 is intended to remain the connected business system of record.

Solar1 is still under development. Buyers should not treat the mapped product direction as proof that every question in this checklist is already supported in production. Solar1 should be evaluated using the same standard recommended here: classify each requirement as live, configurable, integrated, custom, roadmap, or unavailable, and demonstrate the critical workflows with real project data. A buyer-education article only earns trust when the company publishing it is willing to accept its own test.

The checklist is only useful when it changes the buying process

Do not email the checklist to five vendors and choose the highest optimistic total. Identify critical requirements, require evidence, run the same messy project, call comparable references, and review implementation and exit terms before signing.

One missed requirement can create a workaround that survives for years. One clearly defined requirement can prevent the purchase of a tool that looks impressive but fails where permits, materials, crews, finance, and customers meet. Use the checklist to make the vendor follow your project instead of making your project follow the demo. Then download the full 75-question scorecard and take it into the next requirements workshop, demo, and reference call.