--- title: "Expenses" slug: workspace/expenses url: https://projectri.com/docs/workspace/expenses section: workspace audience: workspace app_route: "/[slug]/[user]/expenses" permissions: [finance.expense.manage, finance.expense.approve, finance.expense.view, finance.expense.override] mobile: "/expenses" updated: 2026-09-08 source: Projectri documentation --- # Expenses File a folder of receipts in one sitting, claim mileage and per diem at computed rates, and — if you approve — work the queue of submitted claims. ![Expenses](https://projectri.com/docs-shots/workspace-expenses.png) ## What it is Expenses is the bulk surface for claims. Drag a month of receipt photographs in, each one is read as it uploads, and you check the numbers and file them. Mileage and per diem are separate modes because their amount is computed from the journey rather than typed. A fourth tab is the approver's queue. ## How to get there Expenses is in the main navigation. The row appears for anybody holding **either** `finance.expense.manage` — the key that records a claim — or `finance.expense.approve`. Two features live behind one route and the second is somebody else's key; gated on `manage` alone, a team lead who may only approve could not reach the queue that exists for them. Which tabs you get follows from that. **Receipts**, **Mileage** and **Per diem** need `finance.expense.manage`; **Approvals** needs `finance.expense.approve`. Neither is shown to somebody who would only meet a refusal. How much you see is decided by the server. `finance.expense.view` — a sensitive key — shows every claim in the workspace; without it you see your own, which is the point: the person who submitted a receipt has an obvious right to see what happened to it. The line under the title says which. `finance.expense.override` allows approving a claim that breaches policy. There is no plan gate on this screen. ## How to use it ### File a folder of receipts 1. Drag the files onto the page, or press **Choose receipts**. Images and PDFs only; anything else is skipped with a count. 2. Rows appear immediately and fill themselves in as each receipt is read — amount, currency, date, vendor and category. 3. A field the reader was unsure about is outlined and marked **check**. The value stays in the box, because dropping it would hide the one thing you need in order to correct it. 4. Anything you type is kept. A correction made while the receipt was still being read is never overwritten by the answer arriving second. 5. Set the project and untick **Rebill to the client** where it does not apply. 6. **File** submits one row. Filing is submitting — the claim goes straight to the approver's queue rather than sitting as a draft. ### File everything that is ready 1. The header button files only rows that are complete **and** carry no low-confidence field and no warning. 2. Anything held back is counted in a strip at the top, which says why — a missing amount or date, or a flagged reading. 3. That is stricter than the per-row **File** button, deliberately. Somebody pressing File on one row has that row's number under their eyes; somebody pressing file-all has a total. ### Claim mileage or per diem 1. Switch to **Mileage** or **Per diem**. 2. There is no amount field. The figure is computed from the journey and shown live, with its breakdown — *142 km × 0.45* — beside it, so the number is arguable before it is submitted. 3. Where no rate is configured, the form says so in a sentence rather than quietly producing nothing. 4. Your filed claims stay listed underneath, so the computed amount appearing in the list is the confirmation. ### Answer a policy finding on your own claim 1. Filed claims are listed at the bottom of the receipts tab and under both claim forms. 2. A flagged claim expands to quote the finding in full. 3. Write the justification and save it. Only the person who filed the claim may write it — an approver writing their own justification makes the record worthless. 4. **Re-check** re-evaluates the claim, because the commonest way a violation goes away is that the missing receipt gets attached. ### Approve claims 1. Switch to **Approvals**. 2. **Approve all** takes only clean rows, and says how many it is leaving behind. 3. A flagged row cannot be approved from the list — it expands, so the finding and the claimant's justification are read before the decision, which is the entire reason the policy engine exists. 4. Your own claim is never approvable here. The server refuses it and the row says so rather than offering a button that fails. 5. Where you hold the override key the button reads **Override and approve**, because approving a breach is a different act and the audit record already treats it as one. 6. A row is re-evaluated on the server at the moment of approval, so a claim that was clean when the queue loaded and has since been flagged is caught. ## What it affects - **Project cost.** A filed expense lands against its project and, where billable, is rebilled to the client through the ordinary finance path. - **Currency.** The amount is converted to the workspace's reporting currency once, when it is filed, and the rate used is stored. An expense in AED entered today and read next quarter still says what it cost, not what the same dirhams would cost after the rate table moved. - **The card queue.** A filed expense becomes a candidate for matching against an imported card transaction — see [Cards](/docs/workspace/cards). - **Policy.** Policies flag; they do not block, except where a rule is explicitly set to. Hard-blocking submission produces creative miscategorisation, which is worse than a visible violation. - **Extraction accuracy.** Filing records which of the proposed fields you left alone. A field you corrected is not reported as accepted, so the accuracy figure is not just a count of how often somebody pressed File. ## On mobile The phone owns the **single receipt at the moment it is handed over** — photograph it and it is filed before you put your wallet away. The Expo app also lists your claims, shows what policy said about each, and lets you write the justification, because the claimant is the only person who can answer a finding. Approving is a separate screen there and only appears for somebody holding the key. ## Limits and gotchas - Uploads run four at a time. Dropping forty photographs must not open forty parallel requests; this keeps the first row reviewable within a second while the rest arrive behind it. - A failed upload does **not** lose the claim. The row stays typable and files without an attachment, labelled *not attached*. - A receipt that could not be read is a row to fill in by hand, not a dead one. - Expense policies resolve client, then team, then workspace, and limits are compared **after** conversion at the expense date. Comparing raw amounts across currencies is a bug that looks exactly like a policy. - The filed list reads at most 100 claims. ## Related - [Cards](/docs/workspace/cards) — everything that was actually spent, against what was filed. - [Projects](/docs/workspace/projects) — where a claim's cost lands. - [Approvals](/docs/features/approvals) — how decisions are routed elsewhere in the product. ## Related - [Corporate cards](https://projectri.com/docs/workspace/cards.md): Everything that was actually spent on company cards, and whether each transaction has an expense against it — the reconciliation queue, the import and the card list. - [Projects](https://projectri.com/docs/workspace/projects.md): The project list and the project itself — its people, milestones and progress, its tasks as a table, board, timeline or roadmap, and its documents, boards and meetings. - [Approvals](https://projectri.com/docs/features/approvals.md): The two things in Projectri that wait for a person to say yes — an approval chain on a task, and an AI agent asking permission before it changes anything.