Does Solar Accounts publish a public API?
No. Solar Accounts is a UK desktop accounting package with no API of any kind. The only data-integration topic in Solar Accounts' own help material is CSV import. There is no API, no SDK, and no webhook documentation anywhere on the vendor site.
What does that mean for card and expense automation?
With nothing published, no card or expense platform can offer a supported direct sync into Solar Accounts. Card spend reaches a desktop system like this one of two ways: someone keys each charge in against nominal codes and departments, or the finance team imports a file laid out the way Solar Accounts expects.
Manual keying is what most teams fall back on, and it is where the month goes. The statement arrives weeks after the spend, receipts have to be chased from the people who made the charges, and every line still needs coding before it can be entered. Until that happens, the spend is invisible in reporting.
How does Vergo work with Solar Accounts?
Vergo makes the file path behave like automation. Cardholders code each transaction in Vergo at the moment of spend — nominal code coding, receipt captured on the phone — and approvals run before anything leaves Vergo. Vergo then produces a custom-built CSV export matched to the import format Solar Accounts expects, so the accounting team loads one coded batch instead of rekeying a month of activity or reshaping a bank download in a spreadsheet.
Vergo does not claim an API sync with Solar Accounts, because Solar Accounts does not publish one for anyone to use. What Vergo provides is the working path: coding captured once, at the source, and a ready import file at close.
What does the finance team see while the month runs?
This is the part manual entry cannot give you. Because every charge is coded and receipted in Vergo as it happens, the finance team can see committed card spend by nominal code before the statement arrives and before anything is imported. Budget owners get a live picture rather than a retrospective one, and the import at close becomes a confirmation of numbers people have already seen.
Card controls sit in the same place. Limits, merchant restrictions, and per-card rules are set in Vergo, so overspend is prevented at the point of purchase instead of being discovered during coding. For a desktop system with no API surface, that front-end control is what closes the gap: the ledger stays the system of record, and the mess never reaches it.
Could Solar Accounts open an API later?
Possibly. Vendors add developer interfaces when enough of their customers ask for them. But planning a card programme around an interface that does not exist is a bad bet, so treat file-based integration as the dependable path with Solar Accounts today and revisit if the vendor publishes documentation.
What should you ask a vendor claiming a Solar Accounts integration?
Ask exactly how the data moves. If the answer is a file the customer imports, that is a CSV integration and it should be described as one. Ask to see the export run against your own chart of accounts before you sign anything — a file that does not match your nominal code structure creates work rather than removing it.
Does Solar Accounts have a public API?
No. Solar Accounts is a UK desktop accounting package with no API of any kind. There is no developer portal or published documentation for third parties to build against.
Can any expense platform sync directly with Solar Accounts?
Not through a documented interface. Any vendor claiming a direct Solar Accounts sync is either describing a file import or a private arrangement, so ask which.
How does Vergo get card transactions into Solar Accounts?
Cardholders code charges to nominal codes and departments in Vergo with receipts attached, and Vergo generates a custom CSV export matched to the format Solar Accounts imports.
Can the batch be reviewed before it hits the ledger?
Yes. Approvals happen in Vergo before the export is generated, and nothing enters Solar Accounts until your team runs the import.
