Yes. Every serious solar platform connects to QuickBooks, and knowing that answers almost nothing useful.
OpenSolar runs a live QuickBooks Online connector inside its CashFlow module. Scoop Solar connects to QuickBooks Online through its GLOO integration service. Sunbase lists QuickBooks among its accounting integrations. And a large share of small installers are not on solar-specific software at all, they are on JobNimbus, Smart Service or ServiceTitan, all of which connect as well, with JobNimbus supporting both QuickBooks Online and Desktop.
So you will not be typing invoices twice. Good.
Here is the part nobody writing about this seems willing to say. Every one of those integrations was designed around a transaction shaped like this: one customer, one invoice, one payment. That is a plumbing call. It is not a residential solar project, where the customer signs the contract but a lender pays you, the money arrives in three separate draws months apart, roughly a quarter of the contract value never reaches your bank at all because the lender keeps it as a dealer fee, and there is a clock running that can take the first two payments back.
None of that has a field anywhere in the sync.
What actually crosses, according to the vendors
Start with the primary sources rather than the roundups, because the roundups all copy each other.
OpenSolar's QuickBooks Setup Guide describes the scope in one sentence: sync contacts, invoices and payment records. When an invoice is issued in OpenSolar it pushes to QuickBooks automatically, and when it is marked paid the payment record follows to balance the ledger. There is one connection per OpenSolar organization, and setup requires you to map a 0 percent tax rate, creating one manually in QuickBooks if you do not have one.
JobNimbus is the most honest documentation in the category. Its support article on QuickBooks Desktop field mapping ends with this: job costing does not sync, including work orders, purchase orders, material orders and budgets, and vendor bills will not sync either. Ship-to address and notes do not sync either.
Scoop Solar's QuickBooks Online integration is a different animal. It runs through their GLOO service, where a solution engineer maps triggers, actions and fields with you in a sandbox before going live, then keeps adjusting them as your business changes. That is a consulting engagement wearing an integration's clothes: more flexible than a toggle, and more expensive.
| What you want in QuickBooks | Does the sync carry it |
|---|---|
| Customer and project record | Yes |
| Estimate or proposal | Usually |
| Invoice | Yes |
| Customer payment | Yes |
| Supplier bill for modules and inverters | No |
| Purchase orders and material orders | No |
| Budget versus actual per project | No |
| Dealer fee withheld by the lender | No field exists |
| Milestone funding schedule | No field exists |
| Clawback on a cancelled job | No field exists |
The top half of that table is what the vendor marketing pages describe. The bottom half is where solar money lives.
Your money does not arrive as an invoice
This is the structural mismatch, and it is specific to solar in a way it is not to HVAC or landscaping.
A residential solar installer is a specialty construction company that gets paid mostly by a finance company, on milestones. Vertices, a firm that advises solar companies on their finances, lays out the standard three-milestone structure. M1 triggers on contract execution, historically ranging from 25 to 70 percent of contract value, with the high end used by lenders as a recruiting tool for sales organizations rather than a durable term. M2 triggers on installation completion and pays the balance minus M3. M3, usually around 10 percent, releases on permission to operate from the utility.
Read that last one again. Ten percent of every contract you sign is held by a third party and released on an event controlled by a fourth party. Beancount's 2026 guide for solar EPC bookkeeping puts the PTO lag at four to twelve weeks after the crew leaves the roof, and describes TPO funds as settling 30 to 60 days after PTO, and only when every documentation deliverable is filed in the format the fund requires.
Now put that against a sync that moves one invoice and one payment.
Watch out
Almost every solar funding agreement carries a completion timer that starts at M1. Vertices puts the common window at 90 to 150 days. If the project has not reached PTO by then, the lender claws back M1 and M2 on that job, typically by netting it out of your next remittance. At that point you have paid 100 percent of the job cost and hold zero revenue for it. There is no field for that timer in any solar CRM QuickBooks connector, and when the clawback lands it shows up in QuickBooks as a deposit that is smaller than expected, with no explanation attached.
The M1 mistake that makes your books lie
Here is the single most expensive accounting error in residential solar, and the sync will help you make it.
When the lender funds M1 and your platform marks the project paid, the natural move is to let that flow through as revenue. It is cash. It is in the bank. The invoice is marked paid.
It is not revenue. It is an advance on work you have not performed, and on accrual books it belongs on the balance sheet as unearned revenue. Vertices describes the consequence precisely: the misreported revenue makes the company look more profitable than it really is, and it mistimes expense against revenue. Early on you look excellent, collecting cash up front while logging almost no cost. Then installs ramp, sales cool, and you are paying for installs you recognized revenue on weeks or months earlier. Their word for the resulting financials is moody, and they note that it draws scrutiny from banks, because lenders dislike bouncy profit and loss statements.
That pattern repeats annually with your install seasonality. It is not a bookkeeping nitpick. It is the reason a solar company can post its best sales month ever and go cash negative in the same quarter.
The fix is not exotic. Land M1 in a customer deposit or unearned revenue liability, then recognize revenue as the work is performed. Beancount's 2026 guide splits a residential contract into four obligations under ASC 606, allocating roughly 5 to 10 percent to design and engineering, 3 to 5 percent to permitting, 75 to 85 percent to installation, and 5 to 10 percent to inspection and PTO. You do not have to adopt that split exactly. You do have to stop treating a wire from a lender as a sale.
The dealer fee is not a discount
The second missing line is bigger than most owners want to look at.
When you sell a financed system, the lender keeps a dealer fee, sometimes called a merchant fee, out of what they remit to you. How big? Homeowner-facing sources put the range at 20 to 40 percent. Practitioners are blunter. In one r/solar thread on the topic, the original poster listed a 34.75 percent dealer fee on a 25 year Mosaic loan at 3.99 percent and 34.99 percent on GoodLeap at 4.49 percent, and a commenter in the same thread said they had seen fees well above 40 percent. Enphase's Solargraf documentation models a GoodLeap FlexPay product at an 18 percent dealer fee with the fee type set to margin.
The accounting question is what you do with that number, and there are only two answers. One is right.
The wrong answer is to net it: invoice the customer for what the lender actually sent you. Your revenue line quietly shrinks by a quarter, your gross margin percentage looks acceptable because both sides shrank together, and you lose any ability to see what the financing is costing you relative to your cash deals.
The right answer is to gross it up. Book the full contract value as revenue, book the dealer fee to its own account, and treat the lender's wire as settling both. Beancount's guide reaches the same conclusion, calling the dealer fee a contra-revenue or selling expense rather than a discount to the transaction price, specifically to keep gross margin transparent.
By the numbers
OpenSolar's own dealer fee documentation shows why the gross number is the one that matters. Sell at 20,000 dollars with a 10 percent dealer fee and you net 18,000. Raise the price to 22,000 and the fee rises with it, so you net 19,800. Their published formula is system price equals base price divided by one minus the dealer fee percentage, which puts the price to net 20,000 at 22,222.22. Now consider that your QuickBooks sync pushes the 22,222.22 invoice across and never mentions the 2,222.22 that never arrives.
That is the shape of the problem in one example. The number in your CRM is real. The number in your bank is real. The 2,222 dollar difference between them is not modeled anywhere in the connection between the two, so somebody reconciles it by hand every month or nobody does and the books drift.
If your funding schedule lives in a spreadsheet next to the CRM, that spreadsheet is your real system and the CRM subscription is duplicating part of it badly. We build custom CRMs for solar installers where a project holds M1, M2 and M3 as separate funding events with their own dates, payors, dealer fee and clawback deadline, pushing clean, correctly classified entries into QuickBooks instead of one invoice that hides four facts. See how we approach custom CRM work.
What 2026 changed: the payor moved
If you last set up your books before this year, one assumption underneath them is now wrong.
The IRS states that the Section 25D residential clean energy credit is not available for any property placed in service after December 31, 2025. The 30 percent homeowner credit that anchored a decade of rooftop sales is gone for new residential work. The commercial Section 48E credit survives, and it belongs to the system owner.
The practical effect on your ledger is that more residential volume moves to third party ownership, leases and PPAs, because that is now the only structure where anyone captures a federal credit on a home. Under TPO you are not selling to a homeowner. You are a contractor to a fund, and the fund pays on its own schedule, against its own documentation standards, with warranty terms often flowing back to you for years. Beancount's 2026 guide is direct about what that requires: never comingle TPO revenue with direct customer revenue in one general ledger account, because the collection cycles, warranty terms and audit treatment all differ.
Your CRM has one customer field per project, and the connector maps it to one QuickBooks customer. If half your pipeline is now billed to a fund and half to homeowners, that mapping is quietly wrecking your receivables aging every day, and no vendor is going to warn you.
The connector is not free anymore either
Worth flagging, because it is the freshest fact here and the pages currently ranking for this question predate it.
OpenSolar built its reputation on being free, and it is still free to design and sell in. But its Accounting Connectors support article now states the pricing plainly: 49 USD, 69 AUD or 49 GBP per month, a flat monthly subscription for unlimited sync to Xero or QuickBooks, with the first month free and connector data exempt from the standard per project API fees. Operators noticed. A thread in r/Solarbusiness in April 2026 about OpenSolar locking data down broke out the new tiers, including a flat monthly fee for the native QuickBooks or Xero connectors on top of per project API charges.
One detail in that same OpenSolar article deserves more attention than the price does. Among the new features is a daily recap email listing invoices that failed to sync because of missing or invalid ledger or tax settings.
Vendors build daily failure digests when failures are frequent and silent. That is the quiet failure mode in all of these integrations: not an outage, but a document that never posted because a line item had no matching product or the tax mapping was wrong, found at month end when the numbers do not tie.
The four things that break, in order
From the documentation and the operator threads, in rough order of how often they bite:
- A line item with no mapped product. The document does not sync at all. Incentives, rebates, adders and dealer fees are the usual culprits because nobody sets them up as products in QuickBooks first.
- Tax and ledger mapping. OpenSolar requires a 0 percent tax record mapping before the connector works at all. Solar also sits in a messy use tax position, since an installer buying modules under a resale certificate and treating the install as a real property improvement generally owes use tax on those materials at installation.
- Supplier bills that never leave the building. Modules and inverters are your largest cost line, vendor bills do not sync, and somebody codes them to jobs manually or your job costing is fiction.
- The remittance that matches no invoice. One lender wire covering four projects, net of four dealer fees, minus a clawback. No matching rule exists for that in any of these tools.
The fix that actually works
No connector is going to model solar's money shape. You can make QuickBooks model it, and let the connector do the narrow job it is good at.
Treat each lender exactly like a payment processor. When Square or Stripe deposits a net payout, the correct pattern is gross activity first, a clearing account in the middle, then the net deposit matched against it. A solar funder is the same object with bigger numbers and worse timing.
- One clearing account per funder. GoodLeap Clearing, Mosaic Clearing, one for each TPO fund. Every funded project posts its gross contract value here, not straight to the bank.
- A dealer fee expense account. Its own line, never netted, so you can run fee as a percentage of financed revenue by month and see what your financing mix costs.
- Unearned revenue as a liability. M1 lands here and moves to revenue when work is performed, not when cash arrives.
- QuickBooks Online Plus or Advanced. Projects, the feature that produces per project income and cost, is only on Plus and Advanced, and progress invoicing lives there too. Below that you get no job level margin regardless of what your CRM sends.
- A PTO pending report. Every system energized but not fully funded, with the blocker named. Beancount recommends a weekly aged work-in-progress review tagged by milestone due but not billed.
- A clawback deadline on every funded project. M1 date plus your funder's window. This is the one number nothing in your stack tracks and the one that can end the company.
Then let the connector push customers, invoices and payments. That part it does well.
Choosing, by where you actually are
Under about 100 installs a year, mostly cash and simple loans. Any of the connectors will do. Put the effort into the chart of accounts and the clearing account discipline, not into software selection. JobNimbus is the pragmatic pick if you also do roofing, and it is the only one here with real QuickBooks Desktop support if your bookkeeper has not moved. Our rundown of the best CRM for solar companies covers the wider field.
Growing, multiple funders, mixed cash and TPO. This is where off-the-shelf stops fitting. The funding schedule needs to be a first-class object with its own dates and payors, and no solar CRM models it. Scoop's GLOO approach is the honest version of the off-the-shelf answer: hire an engineer to map your workflow, and keep paying for adjustments.
Already running the funding schedule in a spreadsheet. You have made the decision, you just have not moved the budget yet. That spreadsheet is the system of record for the part of the business that determines whether you survive, and it has no permissions, no audit trail and one person who understands it. Our piece on CRM versus field service software for solar walks through that fork.
Note
A useful test before you buy anything. Ask the vendor to show you one project on screen that has been funded at M1, installed, and is waiting on PTO, with the dealer fee visible and the funding deadline visible, and then ask what that project looks like in QuickBooks right now. If the answer involves exporting to a spreadsheet, you have your answer about what the integration actually does.
The one-page version
Yes, solar software integrates with QuickBooks. The integration carries contacts, invoices and payments. It does not carry job costing, dealer fees, milestone funding or clawbacks, and in residential solar those four things are the difference between a P and L you can lend against and one you cannot.
The connector is not the problem. Expecting it to understand a transaction where the signer is not the payor, the payment is not one payment, a quarter of the contract value never arrives, and the last ten percent waits on a utility, is the problem.
Set up the accounts, gross up the fee, park M1 on the balance sheet, and put a date on every clawback window. Then the sync becomes what it was always supposed to be: a way to stop typing invoices twice.