How do card transactions get into Builder Information System?
Builder Information System (BIS) publishes no public API, so no card platform can post charges into it directly. Transactions arrive either by hand — the bookkeeper keying each one in — or by file import. For a contractor with real card volume, the import is the step worth automating.
What does manual entry actually cost?
Each card charge has to be entered with its job, cost code, and GL account, and matched to a receipt that may or may not have made it back from the field. That is hours at month end, and it is where miscoding happens — a charge on the wrong job quietly skews the job cost report until someone notices.
Why doesn't the bank's CSV import cleanly?
The bank export has date, merchant, and amount, and nothing else. No job, no cost code, no account — and not in the layout BIS's import expects. Someone still codes every line and reshapes the file, so the raw export barely helps.
How does the Vergo-to-BIS workflow run?
1. Spend on Vergo cards. Field and office staff use their cards normally.
2. Code in Vergo. Each charge gets its job, cost code, and GL account — coded from the field or by the office — with the receipt captured at purchase.
3. Export. On your close cadence, run the export. Vergo produces a custom-built CSV matched to Builder Information System's import format.
4. Import into BIS. Load the file on the machine where BIS runs. The layout matches, so it imports without remapping.
What shows up in BIS job costing?
Fully coded entries. Because every transaction carried its job and cost code before export, BIS job cost reports reflect card spend at the same detail as entries keyed directly — without anyone keying them.
Who codes the transactions?
Your process decides: the cardholder can code from the field at purchase, or the office can review and code each charge in Vergo before the export runs. The coding is done once, close to the spend, and reviewed before the file exists.
What keeps the export matched to BIS?
Vergo's coding lists mirror your BIS jobs, cost codes, and GL accounts, and the export layout is built once against BIS's import format. When jobs open or close or the chart changes, the lists are updated and every later export still loads cleanly — no per-import remapping.
How long does the cycle take?
The export and import take minutes. The real saving is upstream: coding at the point of purchase instead of at close, and receipts captured when the charge happens rather than collected in envelopes.
Can a card platform post directly into BIS?
No. Builder Information System has no public API, so direct posting is impossible. File import is the working route.
What is in Vergo's BIS export file?
Every card transaction with its job, cost code, and GL account coding, structured as a CSV matched to BIS's import format.
Does job costing survive the import?
Yes — coding is applied in Vergo before export, so imported entries carry full job and cost-code detail into BIS reports.
Where does the import happen?
In BIS itself, on the desktop where it runs. The file comes from Vergo; the import takes minutes on your close cadence.
