Does Passport Business Solutions publish an API?
No — not in the sense an integration needs. Passport Business Solutions (PBS), the on-premise accounting system used by many contractors, publishes no REST API and no web-service integration reference. What PBS documents is database-level access: ODBC connectivity through AcuXDBC and PBS SQL, which lets reporting tools query the underlying data. Database drivers are not an integration API — there is no supported, documented way for a third-party platform to push transactions into PBS programmatically.
What does that mean for contractor expense automation?
It means no card or expense platform can honestly claim a live API sync into PBS. Field spend — fuel, materials, tools, sub-supplier runs — accumulates on card statements, and someone in the office keys it into PBS with the right job and cost coding, weeks after the purchase, from a statement line that says nothing about which job it belongs to. The bottleneck is not PBS; it is producing clean, job-coded transaction data in a form PBS will accept.
How does Vergo work with PBS without an API?
Vergo automates everything up to the import. Vergo issues the company's cards, so every transaction is captured at the point of spend — the receipt, the job, and the cost coding attached by the person standing at the counter, or by rule. Vergo then generates a custom-built CSV export matched to the import format Passport Business Solutions expects, so the file loads through PBS's own import process without a spreadsheet session first.
The cycle becomes: crews spend on Vergo cards, coding happens in the field as it occurs, the office exports a matched file and imports it into PBS. No retyping, no chasing crews for receipts, no guessing jobs from statement lines.
Is a file-based workflow right for an on-premise system?
Yes. PBS runs on your own systems, and a file-based path respects that: nothing connects into your installation, and your controller reviews the export before it touches the ledger. The difference between this and the manual status quo is who builds the file. A generic card statement still needs hours of reshaping and coding; Vergo's export is built against the structure PBS imports, with every line already carrying its job and cost distribution — so the import is a load step, not a data-entry job.
Apply the simple test to any integration claim about PBS: ask to see the API documentation. There is none to show, so the connection is file-based whatever it is called — and the useful comparison between platforms is how much of the file preparation each one automates. With Vergo it is all of it: capture, receipts, job coding, and the export itself, leaving your office the review and the import.
Does PBS have a REST API for integrations?
No. Passport Business Solutions documents ODBC database access via AcuXDBC and PBS SQL, but publishes no REST API or integration reference for third-party platforms to build a supported sync against.
How does Vergo integrate with Passport Business Solutions?
Through custom-built CSV exports matched to the import format PBS expects. Card spend is captured and job-coded in Vergo, then exported as a file that loads through PBS's import process.
Can card transactions carry job and cost coding into PBS?
Yes. Job and cost coding is applied in Vergo at the point of spend — by the cardholder or by rule — so each line in the export arrives already distributed.
Does anything connect into our on-premise PBS installation?
No. PBS stays entirely on your systems. Vergo produces a file, your controller reviews it, and you import it through PBS as usual.
