How does card spend reach the job cost ledger in Xpedeon?
Through a file import. Xpedeon, the construction ERP used for project accounting across international contractors, publishes no public API — the master record shows no documented read or write interface — so there is no supported live sync from any card platform. Charges arrive either keyed by the accounts office or loaded as a structured import file.
Why is uncoded card spend expensive on a job cost system?
Because the job report is the product. A charge sitting in a suspense account or an unallocated card clearing account is cost that a project manager cannot see against their budget. On a fixed-price job, a month of invisible card spend is a month of decisions made against numbers that are wrong. The coding is not admin — it is the thing that makes the ERP useful.
Step one: code the charge in the field
Vergo prompts the cardholder as the transaction posts. The site manager or foreman picks the job, the cost code and the cost type, and photographs the receipt before it goes through the wash. Materials bought at a merchant counter on a Thursday morning are allocated to the right job that morning.
Step two: approvals before month end
Approvals route inside Vergo to the project manager or the commercial team. Because they review recent spend on their own jobs rather than a month-old consolidated statement, they catch the wrong job code while it still means something.
Step three: generate the export matched to Xpedeon's import format
At period end, Vergo produces a custom-built CSV export laid out for the import format Xpedeon expects. Every line carries the job, cost code and cost type, the amount, date and merchant, and the approval record, with the receipt image stored and linked.
Step four: load and reconcile
Accounts reviews the file and imports the batch into Xpedeon. Reconciliation against the card statement is a match on totals rather than a hunt for missing coding, and the card clearing account clears cleanly.
Vergo does not claim an API sync with Xpedeon, because Xpedeon does not publish one. What it claims is that the file route carries fully coded, approved, receipted transactions — which is the part that costs contractors time today.
What about subcontractor and plant hire charges?
Card spend on a construction job is rarely just fuel and consumables. Plant hire deposits, small tool purchases, site welfare and accommodation all land on cards and all belong to specific cost codes. Because the cost code is chosen at the point of spend from the job's own structure, these charges reach Xpedeon allocated rather than pooled in a general overhead account that nobody reviews.
How does this affect the monthly cost value reconciliation?
Commercial teams reconcile cost against value monthly, and card spend that has not been allocated to a job distorts that comparison in both directions. Getting the allocations in before the CVR is prepared means the commercial view and the ledger agree, and margin conversations are about the job rather than about missing data.
What should a contractor check before importing?
Three things: the batch total against the card statement, any transaction still lacking a receipt image, and any line coded to a job that has closed. All three surface in Vergo before the export is produced, so the file that reaches the accounts team is one they can load rather than one they have to fix.
Does Xpedeon have a public API for card transactions?
No. Xpedeon publishes no public API documentation, so no card platform can offer a supported direct sync. Transactions are brought in as a file import.
What job costing detail does the export carry?
Job, cost code and cost type as captured by the cardholder in the field, plus date, amount, merchant and the approval trail, in the layout Xpedeon expects.
How do receipts get captured on site?
The cardholder photographs the receipt in the Vergo app at the point of spend; the image is stored against the transaction and stays linked through the export.
Who imports the batch into Xpedeon?
The accounts team, after reviewing the file. Nothing reaches the job ledger without a person loading it.
