How to automate expense management in IFS

Key takeaways

• An IFS code string is the account plus free code parts, commonly with cost centre in code part B, and project and other dimensions in the rest.
• IFS Expense Administration notes that postings cannot be changed once an expense sheet is authorised, so coding has to be right before approval.
• Card transactions reach IFS from the banks through an inbound interface and appear on the expense sheet's Credit Card tab.
• Vergo proposes the full code string from your history and delivers through the External Vouchers interface.

Where should you go next?

• Vergo's IFS integration
• What expense management software integrates with IFS?
• Get started with Vergo

How do you automate expense management in IFS Cloud, step by step?

1. Enable access. Your IT team enables API access in your IFS Cloud environment once; Vergo then reads your code parts and delivers coded spend through the External Vouchers interface.
2. Connect your existing cards. No bank interface to set up per card program: connecting your existing cards involves no card applications, no re-issuing and no banking change.
3. Collect receipts by text. Employees handle everything by text message — no app to download, no portal login — and Vergo chases missing receipts itself instead of waiting for a report.
4. Code the full string. Vergo proposes the account and each code part you use for every line, with the reason.
5. Deliver to IFS. Approved spend is delivered as external vouchers, already coded, so nothing needs changing after authorisation.

What does IFS need on each card transaction?

• Account: code part A.
• Cost centre: usually code part B.
• Other code parts: project, object, department or whatever your company defined in C to J.
• Expense code: in Expense Administration, codes such as overnight, mileage or taxi define the type of cost and drive the posting.

Where does IFS Expense Administration stop and automation start?

IFS gives you expense sheets, travel requests, approvals and employee payment, plus import of card transactions from the banks. The posting is built by accounting rules from the expense code, and the employee or approver supplies the rest of the code string. Vergo reads the receipt itself, line by line, and predicts the coding from what was actually bought — the account, cost centre and project code parts — not just the vendor name on the header.

A practical example

An aerospace services firm's field engineer pays for tooling and a hotel on a company card during a customer visit. Vergo texts for both receipts, proposes the tooling account with the customer project and service cost centre for one, and the travel account with the same project for the other, citing prior trips to that customer. The manager confirms, and both lines reach IFS as coded vouchers.

How Vergo handles this

Vergo proposes the coding by inference from your own accounting structure and history — no rule library to build, no keyword lists to maintain, and new vendors are coded on first sight. In IFS terms, the history is your posted code strings, so project and cost centre come from how your people actually charged similar work. Approval workflows are optional and fit how you already control spend: route by GL account, by amount, or by project — or skip approval flows entirely and let policy flags catch only what breaks a rule. Card spend, employee reimbursements and AP invoices run through one coding model — same coding, same review, one reconciliation — and payment stays on the rails you already use.