How do reimbursements reach Epicor Eclipse?
Employees submit an expense in Vergo from their phone with the receipt attached. It is coded to branch, warehouse, and general ledger account, routed for approval under your rules, and once approved it posts into Epicor Eclipse over the documented API your IT team enabled. Epicor Eclipse runs cloud or on-premise; the connection sits in your environment either way. The vendor reference is Epicor Eclipse documentation.
What does the submission look like for an employee?
A photo of the receipt, an amount, and the branches and product lines picked from a list that comes from Epicor Eclipse itself. Mileage and per-diem lines follow the same path. There is no spreadsheet template and no PDF to email, which is the reason expenses that used to arrive a month late arrive the same week.
That timing matters more than the convenience does. An expense filed six weeks after the fact lands in a period that is already closed, and the coding is whatever the employee can still remember. Filed the same day, it is coded by the person who was there, against the branches and product lines that actually consumed it.
How does approval work?
Rules run on the dimensions Epicor Eclipse already defines: amount thresholds, branches and product lines, and expense category. A submission routes to the manager who owns the cost, and anything above a limit escalates. Approvers act from email or the phone rather than a queue they have to remember to open, and every decision is stamped on the expense so the audit trail sits with the record instead of in someone's inbox.
Policy is enforced at submission, not in review. A missing receipt, an out-of-policy amount, or a category the employee is not entitled to is flagged before the expense reaches an approver, which removes most of the back-and-forth that makes reimbursement processing slow.
How are reimbursements paid?
Vergo does not replace your payment process. Approved reimbursements post into Epicor Eclipse so they are paid on the same run as everything else, against the accounts you already use. Finance keeps one payment file and one set of controls.
Who uses this in a distribution business?
Typically distributors running counter sales, warehouses, and multiple branches. Out-of-pocket spend in these teams is small per item and constant in volume, which is exactly the category that gets filed late and coded badly. Coding it at submission — to the right branches and product lines — is what makes it reportable.
What if some spend should be on a card instead?
Most teams find that once reimbursements are visible, a large share of them are recurring purchases that belong on a company card. Vergo issues cards on the same coding and approval rules, so moving that spend does not mean adopting a second system or a second workflow in Epicor Eclipse.
The reason to care is cash and control. Reimbursed spend is spend that already happened, at a price nobody approved, on a personal card that carries no limit. Card spend is spend you cap in advance and see the day it occurs.
What does setup involve?
Your IT team enables API access on the Eclipse side once — the access model is customer-provisioned, so the interface stays inside your environment. Vergo then mirrors your chart of accounts and branches and product lines, loads the approval rules, and rolls out to employees. Nothing inside Epicor Eclipse is reconfigured, and the ERP remains the system of record for every posted expense.
Does Vergo handle reimbursements with Epicor Eclipse?
Yes. Employees submit from the phone, approved reimbursements post into Epicor Eclipse through its documented API, and they are paid on your normal payment run.
How are out-of-pocket expenses coded?
At submission, to branch, warehouse, and general ledger account, using lists that come from Epicor Eclipse so the values match the ledger. Mileage and per-diem follow the same coding path.
Does Vergo pay employees directly?
No. Vergo captures, codes, and approves the expense, then posts it into Epicor Eclipse so payment happens through the process and controls you already run.
What does setup require from IT?
One task: enabling API access on the Eclipse side. The access model is customer-provisioned, so the interface stays in your environment and Vergo handles mapping and rollout from there.
