Expense claims, mileage and reimbursements inside your HRIS

Companies where expense claims currently arrive as photographs in a chat thread and get reimbursed on somebody’s memory of who approved what. The buyer is usually finance. It earns its place once you have enough claims that the approval trail matters, or once you are paying mileage and want the rate applied from a dated table rather than typed in by whoever is claiming. If your team files three claims a quarter, the core’s document store and a bank transfer are honestly enough.

A paid plan first, because paid modules cannot be enabled on the free plan. Then the configuration is your policy expressed as data: expense categories, whether each cap is a soft flag or a hard refusal, receipt thresholds where you want one, mileage rate tables with the dates they take effect, whether advances are available, and which reminders are on. The defaults are deliberately permissive, with caps soft, receipts required only where you set a threshold, advances off and reminders off, so the module is usable before you have written a policy. Approvals bind to the same workflow engine your other approvals already use. The work is deciding the policy, not configuring it.

It does not book travel. Travel here means travel-category expenses and mileage; itineraries, bookings and vendor integrations are out. It is not a corporate card programme: it issues no cards, reads no card feeds and reconciles no bank statements. It moves no money, so disbursements, reimbursements and repayments are recorded with a mandatory reference rather than paid from inside Capstan. It ships no per-diem engine and no jurisdiction’s expense policy, though a per diem is expressible as a category with a cap. It does not read your receipts for you: there is no OCR and no currency conversion engine. And contractor expense claims are out of scope in this version.

Claims and advances are ordinary subjects of the core workflow engine, so they route through the same approval machinery, notifications and audit trail as a leave request, and a receipt is a document in the core document store rather than an attachment living somewhere separate. Reporting registers with the core report registry, so expense reports are scoped by the same permissions as everything else. It requires no other paid module. Where Payroll is enabled, approved reimbursements are one of the inputs compiled for your payroll partner if you settle them through payroll rather than separately. If you use outbound webhooks, which are core on every plan, this module emits an event when a claim is submitted and when an approved claim is reimbursed.

Claims, advances, categories, mileage rate tables and the expense reports stop being reachable, and billing stops at the end of the current period rather than on the day. Your expense data is not deleted: it is retained on a schedule and restored if you re-enable within that window, and a full workspace export includes module data whether or not the module is currently enabled. Receipts remain documents in the core document store under the same visibility rules as any other document. Nothing in the free core changes.

Per employee per month, on the same roster count your plan bills on, rather than on the number of claims filed. Someone who never submits an expense still counts, which is the honest trade for a module priced low and flat instead of metered per claim. It is not billed per approval, per receipt or per amount reimbursed, and the price does not move with the value of what you reimburse. Every figure is on the pricing page.