Reimbursements & Expenses

What it is

The Expenses module is a native reimbursement and expense workflow that lives in TATER Ops. A single request can hold many line items — one per receipt — and each line is marked either reimbursable (out-of-pocket money the company owes you back) or company-card (already paid on a corporate card, captured only so finance can reconcile it). It replaces the fragile "Microsoft Form → Power Automate → spreadsheet row" intake that can silently break and drop submissions: in TATER, a failed submission is a visible error you can retry, never a silent gap.

How a request flows

• Submitted — you create the request with one or more line items. If any line is reimbursable and you supplied an approver — a member or an approval group — it appears in their My Approvals inbox.
• Approved / Rejected — an approver (or AP from the queue) decides. Approving means the reimbursable amount is cleared to pay.
• Paid — AP marks an approved request paid once the money is disbursed, optionally recording a payment reference (check #, ACH id).
• Logged — a request whose lines are all company-card has no payout, so it skips approval entirely and is recorded as Logged for reconciliation.

Submitting an expense

You can submit from two places — both use the same form:

• TATER Ops → Workspace → Expenses → + New expense
• My TATER → Personal → My Expenses → + New expense (the natural home for most employees)

For each line, enter the amount, a short description, the transaction date, and pick the payment type. Optionally add a category (travel, meals, supplies…) and attach a receipt image or PDF. Add as many lines as you have receipts, then submit. If you give an approver, reimbursable lines route straight to them; if not, AP picks it up from the queue.

Who the approver can be

An approver is either one member of your organization, or a reusable approval group — see the Universal Approval Engine for how groups are defined. A group is what a shared AP function usually wants: every member sees the request in their own My Approvals, and the group's decision mode (any one / all / quorum / percentage) applies.

A shared mailbox address is not an approver. Routing to one used to be accepted and produced a request nobody could act on: the notification reached whoever reads that mailbox, but My Approvals filters by the signed-in identity, so the person opening it was told there was nothing to approve — and the request could not be re-routed either, because it already held a pending approval. TATER now rejects an approver address that is not a member of the organization and tells you to use a member or a group instead. If AP wants a copy in the shared mailbox as well, forward it on the mail side; the approver itself must be an identity that can sign in.

Re-assigning an approver on a request that already has a pending approval now supersedes it — the old approval is cancelled and logged, and a fresh one is raised for the new approver. Previously this was refused, which left any misrouted request permanently stuck.

Where to set it. On the submit form, …or an approval group appears under the approver email box once groups exist (listing them needs Auditor or above, so most submitters see only the email field). On an existing Submitted request, Assign approver — Reassign approver when one is already routed — offers the org's groups first, with A specific person… to name one instead.

Receipts

Each line can carry one receipt (image or PDF, up to 12 MB). Receipts are stored in the same secure attachment store as Ops ticket attachments and are retained for audit. Anyone who can view the request — the submitter or an admin — can open a receipt via a short-lived secure download link.

The AP queue (admins)

Org admins see an AP queue in Ops → Expenses (switch the scope selector to "AP queue (all)"). From there you can:

• See KPI tiles — how many requests await a decision, the total approved-but-unpaid amount (pending payout), total paid, and total company-card spend logged.
• Open any request, review its line items and receipts, and Approve or Reject it.
• Mark paid on an approved request once the money goes out, with an optional payment reference.

Approvals also surface in My Approvals across the suite, so an approver can act there without opening the AP queue.

Reporting

• TATER Insights → Reimbursements & Expenses gives a per-employee breakdown — reimbursable submitted, paid, pending payout, and company-card spend — plus a status mix and the top spenders. Use it for period totals and company-card reconciliation.
• Every action (submit, approve, reject, pay, cancel) is written to the activity log, so the whole lifecycle is auditable.

For AI agents (MCP)

Six MCP tools let an AI assistant work expenses end-to-end:

• list_expense_requests (read) — your own requests, or the AP queue with scope=queue (Admin).
• get_expense_request (read) — full detail of one request including line items and receipts.
• create_expense_request (write) — submit a multi-line request on your behalf. Takes approver_email or approver_group_id.
• assign_expense_approver (write, Admin) — designate or re-assign the approver on a Submitted reimbursement, to a member or an approval group. Supersedes any pending approval.
• decide_expense_request (write, Admin) — approve or reject a submitted request.
• mark_expense_paid (write, Admin) — mark an approved request paid.

Notes & limits

• You can only see and act on your own requests unless you are an org admin (who sees the whole AP queue).
• A request can mix reimbursable and company-card lines; the status tracks the reimbursable workflow while the company-card lines ride along as logged records.
• You can cancel any request that has not been paid; admins can cancel on a submitter's behalf.
• Receipts are uploaded after the request is created (the submit form does this automatically), so the create step stays fast even with several large receipts.