How do card transactions actually get into Vadim-iCity?
By import, or by keyboard. Vadim-iCity publishes no API, so there is no third option. The choice a municipality really makes is whether the coding on those transactions was captured at the point of purchase or reconstructed by the finance office weeks later from a statement.
Step one: code at the point of purchase
Vergo notifies the cardholder the moment a charge posts. The employee selects the fund, department and account code, adds a short description of what the purchase was for, and photographs the receipt. For a municipality this is the entire audit story, captured in about fifteen seconds by the person who has it firsthand.
Step two: route approvals to the budget owner
Approvals run inside Vergo to the department head, with finance thresholds layered on where the entity wants them. Because the review happens in the same week as the purchase, a questionable charge is questioned while the answer is easy to get.
Step three: build the export in Vadim-iCity's import layout
At period end Vergo generates a custom CSV export matched to the import format Vadim-iCity expects. Fund, department and account coding is already applied on every row, along with date, amount, merchant and the approval record. Finance reviews the batch, not the individual charges.
Step four: import and reconcile against the statement
Finance loads the file into Vadim-iCity. Reconciliation is a total-to-total match, because the batch was assembled from approved, coded transactions rather than from a raw bank download. Corrections happen in Vergo and the export is regenerated before loading.
Why is this worth changing?
The manual route puts a month of coding decisions on one or two people in the finance office, at the worst possible time, with the least information. It produces late journal entries, chased receipts, and budget reports that lag actual spend. Moving coding to the point of purchase fixes the timing problem and the documentation problem in the same step.
There is no API sync with Vadim-iCity to claim. Vergo offers a file import that arrives complete.
What about cards issued across departments?
Municipal card programs usually span public works, recreation, administration and utilities, each with its own budget owner. Vergo sets limits and approval routes per department while still producing one export for the finance office, so departments keep control of their own spend without creating four separate month-end processes.
What documentation should each transaction carry?
Fund, department and account coding; a plain-language business purpose; the receipt image; and the approver with a timestamp. That set answers almost every audit question that gets asked about purchasing cards. Captured at the point of purchase it costs the employee seconds; reconstructed at close it costs the finance office days and often cannot be completed at all.
What should finance check before importing?
Batch total against the card statement, any transaction still missing a receipt, and any coding that falls outside the department's normal accounts. All three are visible in Vergo before the export is generated, which is the point — the review happens on a complete, coded batch rather than on a raw download that still needs work.
Is there an automatic sync between Vergo and Vadim-iCity?
No. Vadim-iCity publishes no API. The route in is a structured CSV export that Vergo generates in the import format the system expects.
What coding is applied before export?
Fund, department and account code, captured by the cardholder at the point of purchase and confirmed by the approver.
Can the finance office change coding before import?
Yes. Corrections are made in Vergo and the export is regenerated, so the batch loaded into Vadim-iCity is always the corrected one.
How are receipts retained for audit?
Receipt images are stored in Vergo against each transaction, alongside the approver and timestamps, and remain retrievable for audit or records requests.
