Why file import, not a live feed?
Sage 500 ERP has no public API — Sage's guidance is that programmatic access requires a licensed SDK built on SQL staging tables. No card platform can push transactions into your on-premise Sage 500 instance through a supported public interface. Card spend therefore enters Sage 500 the way batch data always has: keyed by hand or imported from a correctly formatted file.
The month-end problem the import should fix
The typical routine: card statements arrive, AP chases cardholders for receipts and coding, every line gets allocated to an account and department, and someone keys or loads the batch. The data entry is not the real cost — the coding and the chasing are. The person doing the entry rarely knows what the purchase was for, so each ambiguous line becomes an email thread.
The workflow with Vergo
1. Code at the point of spend. Cardholders tag each Vergo card transaction to the right account and department when they make the purchase, and photograph the receipt in the same step.
2. Approve continuously. Managers and finance approve in Vergo as transactions come in, not in a statement pile at month end. Miscoded lines get fixed while the context is fresh.
3. Export in Sage 500's format. Vergo provides custom-built CSV exports matched to the import format Sage 500 expects — the column layout, account references, and department fields arranged so the file loads without manual rework.
4. Import and review. Your team loads the batch into Sage 500 and reviews it. Every line is already coded, approved, and receipt-backed.
What belongs in the import file?
Date, amount, vendor, the GL account and department allocation, and a reference tying the line back to its receipt in Vergo. Because the allocations were made by the cardholder and confirmed in approval, what lands in Sage 500 reflects what actually happened — not an AP clerk's best guess from a statement descriptor.
How this compares to the alternatives
Manual entry works but scales with card count; twenty cards can mean days of coding each close. Custom SDK development against Sage 500's staging tables is possible with SDK licensing, but it is a build-and-maintain commitment most teams do not want for expense data. A generic bank export still leaves every line uncoded. Vergo's matched export sits in the practical middle: no custom development, no re-keying, and the coding done before the file exists.
What this is not
It is not an API sync, and transactions do not appear in Sage 500 in real time. They appear when you run the import, on your cadence. For a system whose vendor offers no public API, a clean, coded, scheduled import is the honest ceiling — and it removes the hours that were actually being lost.
Can transactions post into Sage 500 automatically?
No. Sage 500 has no public API, so there is no supported path for automatic posting. Vergo produces import files in the format Sage 500 expects instead.
What format does the export use?
A custom-built CSV matched to Sage 500's import layout — accounts, departments, and references arranged so the batch loads without editing the file.
Who does the GL coding?
Cardholders code transactions in Vergo at the point of spend, and finance confirms in approval. The import file carries those allocations into Sage 500.
Does this work with an on-premise Sage 500 install?
Yes — that is the point of the file path. The import runs inside your environment against your instance; nothing external connects to your database.
