Why is this an import rather than a sync?
RedSky publishes no public API documentation and has no developer portal, so there is no documented interface for a card platform to sync through. That leaves the routes RedSky supports for outside data: manual entry, and file import in a layout the system accepts. Choosing the file route deliberately, and building the file properly, is what separates a smooth month end from a bad one.
What does the manual route cost?
The card statement lands after the period it covers. The accounts team prints it, emails site managers about charges nobody recognises, waits on receipts from vans and site offices, then codes each line to a job and cost code before keying it. Until that is finished the cost report on every job is understated by whatever went on cards — the number a commercial manager wants while the job is live, not after final account.
How do you import card transactions instead?
- Code on site. The cardholder picks the job and cost code in Vergo when the charge posts, at the merchant, not weeks later.
- Photograph the receipt. Captured on the spot and attached to the transaction, ending the receipt chase.
- Approve. The site or commercial approver reviews in Vergo; miscoded lines are corrected before anything is exported.
- Export and load. Vergo generates a custom-built CSV export matched to the import format RedSky expects, and the accounts team loads it as a single batch.
What has to match in the export?
Your job codes and cost codes exactly as RedSky holds them, plus supplier, date, amount, and any nominal or analysis segments your install requires, in the column layout your import reads. Vergo builds the export against your file, which is what makes it load cleanly rather than fail on the first row. Teams that analyse subcontract and material spend separately usually want those segments carried through as well, so the batch lands already split rather than needing a journal to correct it.
What changes at period end?
The accounts team stops reconstructing the month. Coding was done by the person who spent the money, receipts are already attached, approvals are already recorded, and the import is a reviewed file rather than an interpretation of a bank statement. Job costs reflect card spend inside the period it belongs to, and queries get answered from the transaction rather than from memory.
What about the audit and documentation trail?
Every transaction in Vergo carries who spent, what they said it was for, the receipt image, the approver, and the coding at the time of approval. That answers the queries an auditor, an owner's quantity surveyor, or your own commercial team raises against a job, without anybody assembling a folder after the fact. The export moves the coded transaction detail into RedSky; the supporting documentation stays retrievable against each charge.
Is anything automatic that should not be?
No. The export is generated on demand, it is reviewable as a file before it goes anywhere, and nothing enters RedSky until someone in the accounts team loads it deliberately.
Can RedSky import credit card transactions from a file?
File import in the layout your install accepts is the practical route, since RedSky publishes no public API for a live sync.
What does Vergo give the accounts team?
A custom-built CSV export matched to RedSky's import format, with every charge already coded to job and cost code and a receipt attached in Vergo.
Do site staff need RedSky access?
No. They code in Vergo on their phones against jobs and cost codes; the RedSky-side layout is handled by the export.
How often should the export run?
Most teams run it on the card cycle or at period end. Because coding happens at the point of spend, the timing is a preference rather than a scramble.
