How do you import credit card transactions into Tyler Incode?

What is the fastest way to get p-card charges into Tyler Incode?

Stop treating the card statement as the starting point. Tyler Incode — marketed as ERP Pro — has no published public API, so the charges arrive by file or by hand either way. The difference between a painful close and a quiet one is whether the coding was captured when the purchase happened or reconstructed afterward.

Step one: code the purchase at the register

When a department employee uses the card, Vergo prompts them immediately. They select the fund, the department and the account code, and photograph the receipt. This takes seconds and happens while the purpose of the purchase is still obvious to the person who made it. Finance is no longer the party guessing.

Step two: clear approvals during the period

Approvals route inside Vergo to whoever owns the budget — a department head, a finance director, or both, depending on thresholds the entity sets. Questions get asked in the same week as the spend, not against a statement that arrived a month later. Anything unresolved is visible before close instead of surfacing during it.

Step three: generate the export matched to Incode's import format

At period end, Vergo produces a custom-built CSV export laid out for the import format Tyler Incode expects. Every row carries the fund, department and account coding already applied, the amount and date, and a link to the stored receipt image. Finance reviews the file as a whole rather than transaction by transaction.

Step four: load the batch and reconcile

A finance staff member imports the file into Incode. Because the batch total is known before the load and every line was approved in advance, reconciliation against the card statement is a matching exercise rather than an investigation. If a line needs to change, it changes in Vergo and the export is regenerated.

What does this replace?

It replaces the spreadsheet. The common alternative is downloading a bank export, opening it in Excel, adding coding columns by hand from memory or from email threads, chasing missing receipts, and pasting the result into an import template. That work is the same work every month, and it is the work that keeps p-card spend from showing up in the ledger on time.

There is no API sync with Tyler Incode to claim. Vergo claims the file path done properly: coded once, at the point of purchase, and imported as a reviewed batch.

How does this hold up in an audit?

An auditor testing purchasing-card spend asks for the receipt, the business purpose, the coding and evidence of approval. When those four are captured at the point of purchase and carried into the import batch, a sample is answered from the record in minutes. When they were reconstructed from a statement at close, the same sample turns into a search through inboxes, and the gaps that turn up become findings.

Who should be responsible for coding?

The person who made the purchase, not the finance office. Finance can define the available funds, departments and account codes and constrain what each cardholder may select, but the allocation decision belongs to whoever knows why the money was spent. Centralising that decision is what makes month-end slow and the coding unreliable at the same time.