Why can't card transactions sync into Solar Accounts automatically?
Because there is nothing to sync through. 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. That leaves two ways in: keying charges by hand, or importing a file laid out the way Solar Accounts expects.
What does the manual route actually cost?
A UK small-business owner or their bookkeeper typically waits for the statement, chases receipts from everyone who used a card, codes each line to nominal codes and departments, then types the batch in. The work is not hard, it is just long, and it happens in the narrow window when close is already tight. Anything missing a receipt gets parked in a holding account and cleaned up later, which is how coding errors survive into reporting.
How do you import card transactions into Solar Accounts with Vergo?
The sequence is short:
- Spend on a Vergo card. The transaction appears in Vergo the moment it clears, with merchant and amount already attached.
- Code it at the source. The cardholder assigns nominal code coding and photographs the receipt from their phone, while they still remember what the charge was for.
- Approve. Reviewers clear or query lines in Vergo. Nothing moves toward the ledger until it is approved.
- Generate the export. Vergo produces a custom-built CSV matched to the import format Solar Accounts expects — your chart of accounts and your coding structure, not a generic bank download.
- Import into Solar Accounts. Your finance team runs the import and reviews the batch before posting.
What makes a matched export different from a bank CSV?
A raw bank export gives you dates, merchants, and amounts in whatever order the issuer chose. Someone still has to reshape the columns, add the nominal code coding, and reconcile receipts separately. A matched export is built against your Solar Accounts setup, so the file arrives in the column order and code values the system accepts, and the coding is already carried on each line.
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.
How often should you run the import?
Most teams run it weekly and again at close. Because coding happens at the point of spend rather than after the statement, running it more often costs almost nothing and keeps the nominal code view in Solar Accounts current instead of a month behind.
To be exact about what this is: Vergo does not claim an API sync with Solar Accounts. It is a file-based path, built to your import format and driven by coding that already happened in the field.
Can Vergo push card transactions into Solar Accounts automatically?
No — and no vendor can, because Solar Accounts publishes no public API. Vergo generates a CSV export matched to its import format for your team to load.
What coding is carried in the export?
Whatever your Solar Accounts setup uses — nominal codes and departments — captured by the cardholder at the time of spend rather than reconstructed at month end.
Where do receipts live?
In Vergo, attached to each transaction and captured by phone at the point of spend, so the audit trail is complete without paper travelling back to the office.
How long does the import take?
Minutes. The batch is already coded and approved, so the finance team is importing and reviewing rather than keying and chasing.
