Why is there no automatic card feed into BuildSmart?
RIB BuildSmart does not publish a public API, so no card platform can post transactions into it directly. Whatever card program a BuildSmart contractor runs, the transactions end up entered by hand or imported from a file. The practical question is not whether you will import a file — it is how much manual work happens before that file exists.
What does the manual process look like today?
On most BuildSmart sites the month-end card routine looks like this: the statement arrives, someone chases cardholders for receipts, each transaction gets coded to a contract, job, and cost code, and the accounts team keys or imports the batch. The coding is the slow part — the person entering the data usually was not the person who spent the money, so allocation questions bounce back and forth while the close waits.
How does the import work with Vergo?
Vergo moves the coding to the point of spend and hands your team an import-ready file.
1. Cardholders code as they spend. Each Vergo card transaction is tagged to the right job and cost code by the person who made the purchase, with the receipt captured on their phone at the same time.
2. Finance reviews and approves. Approvals happen in Vergo, continuously, instead of in a statement scramble at month end. Anything miscoded is fixed while the purchase is still fresh.
3. Vergo produces the import file. Vergo provides custom-built CSV exports matched to the import format BuildSmart expects — columns, references, and job and cost-code fields laid out so the file loads without rework.
4. Your team imports into BuildSmart. The batch arrives coded, approved, and receipt-backed. The import step is a review-and-load, not a data-entry project.
What should the import file contain?
For construction cost control the fields that matter are the transaction date, amount, supplier, the job and cost-code allocation, and a reference back to the receipt. Vergo's export carries the coding done in the app, so the allocations in BuildSmart match what the cardholder tagged in the field — no re-interpretation from a bank statement line.
How is this different from exporting a bank statement?
A bank statement export gives you dates and amounts with no job costing. Someone still has to code every line before BuildSmart can use it. Vergo's export is different because the coding, receipt matching, and approval happen before the file is generated. The file is the end of the process, not the start of it.
Honest limits
This is a file-based workflow, not an API sync. Transactions do not appear in BuildSmart in real time — they appear when your team runs the import, on whatever cadence suits your close. For a system without a public API, that scheduled, clean import is the most automated path available, and it removes the part of the job that actually costs time: the coding and the chasing.
Can Vergo post transactions directly into RIB BuildSmart?
No — BuildSmart publishes no public API, so nothing can post into it directly. Vergo provides custom-built CSV exports matched to BuildSmart's import format instead.
Who codes the transactions to jobs and cost codes?
Cardholders do, in Vergo, at the point of spend — with receipt capture on the same step. Finance approves in Vergo before anything is exported.
How often can we import into BuildSmart?
On whatever cadence your team runs the import — weekly, or at month end. The file is generated on demand from approved transactions.
Do we still need to keep paper receipts?
Receipts are captured digitally in Vergo and stay attached to each transaction, so the audit trail lives with the spend record rather than in a folder.
