How to write a startup expense policy

Expense policy for startups is the written spend rules your team can follow without a Slack argument. Nautis does not sell a document called Expense Policy. What it does ship in Expenses is Policy Rules that warn or block violating submissions, plus categories, budgets, receipts, and approval chains. Write the policy first, then encode the bright lines as Policy Rules. This is operating guidance. It is not legal or tax advice.

Begin from the receipt that caused the fight

Illustrative incident: Nova Labs (composite only) expensed a $180 client dinner with alcohol on a company card. Finance rejected it two weeks later. Sales said the policy was "be reasonable." Nobody could point to a sentence. Expense policy for startups fails when it lives only as a vibe.

Write the policy the same week as the incident, while the receipt is still in hand. Hold Nova's dinner through the clauses below.

Expense policy for startups also fails when finance invents rules after the fact in a rejection comment. Retroactive rules feel personal. Written rules feel fair even when they sting. Capture the disputed line items in plain language: merchant, amount, category claimed, who approved verbally if anyone did, and why finance objected. That scrap becomes clause drafts, not a public shaming thread.

Illustrative scrap from Nova (composite only): merchant listed as a steakhouse; line items included two bottles of wine; Description said "customer dinner"; no pre-approval note; card was company Amex. The policy gap was alcohol plus missing pre-approval for entertainment over a quiet threshold nobody had written down.

If legal or employment counsel needs a longer handbook section, keep that as an appendix. The operating one-pager is what cardholders see before they tap Pay. Expense policy for startups that only lives in a fifty-page handbook will not stop the next receipt fight.

Purpose should name the company and the date. Who may spend should list roles, not only names, so turnover does not void the page. Pre-approval should name channels: Slack thread tagged #approvals, email to a role, or a Task Board card with an Approver. Hard no lists should be short enough to memorize. Caps should state currency and per-person versus per-party rules so a four-person meal is not argued as four times a vague "reasonable dinner."

Documentation rules should say what counts as a receipt: itemized PDF or image, not a bank statement line alone. Enforcement should separate product blocks from human escalation: Policy Rules catch bright lines; a named finance owner handles gray travel and customer entertainment exceptions with a dated note.

Expense policy for startups on one page

Keep expense policy for startups to one page. Longer PDFs do not get read on mobile.

1. Purpose: company money pays for company work, with receipts.
2. Who may spend: named roles and cardholders.
3. Pre-approval: what needs a yes before purchase (travel over a threshold, new SaaS, gifts).
4. Hard no list: alcohol on company card, personal items, unspecified "team bonding" without an owner.
5. Caps: meals per person per day, hotels, ground transport.
6. Documentation: receipt required above a dollar amount; Description must state purpose.
7. Enforcement: warn versus block in tools, and who escalates exceptions.

Illustrative Nova clause set after the dinner: no alcohol on company cards; meals capped at $50 per person per day unless a VP pre-approves in writing; Description must name the customer or project.

Warn versus block table

Encode bright lines in Expenses (checked 31 Oct 2026). Admins open Policy Rules in the sidebar and create rules that warn or block expenses that violate policy, for example "no alcohol on company card" or "meals capped at $50 per day." Submitters get an inline warning when they break a policy rule before they save. Approval rules, policy rules, and category management need additional admin permission.

Expense policy for startups that only exists in Notion while Policy Rules stay empty will lose the next dinner fight the same way.

When you create a Policy Rule, reuse the exact phrase from the one-pager so trainings match the product. If the page says "no alcohol on company card," the rule example in help is the same shape. Submitters who see an inline warning before they save can fix category, amount, or Description without a two-week rejection cycle. Prefer warn while the team is learning a new cap, then switch to block once overrides stop teaching anyone.

Do not encode every soft preference as a block. Soft preferences belong in the one-pager as guidance. Blocks belong to lines you will defend in front of a VP who wants the customer dinner to post anyway. That split keeps Policy Rules respected instead of routinely overridden.

Wire categories, budgets, and runway habits

Expenses is where you log spend, attach receipts, sort by category, and watch spend against budgets. Categories keep expenses neat and make budgets work: sidebar Categories, Add Category, Name and Colour. Match category names to your operating chart so policy caps attach to real buckets.

Recompute runway the day headcount or major spend changes, not only at month end. Use Startup Health cash, MRR, and burn for that check. For burn labels, see How to calculate startup burn rate and runway. Policy caps without runway habit still allow quiet overspend inside "allowed" categories.

Budgets in Expenses watch spend against limits you set. Pair a meal cap Policy Rule with a monthly entertainment budget so warn-or-block at submit time and budget alerts at the period level both fire. Categories keep expenses neat and make budgets work; rename or add categories when policy buckets change rather than stuffing new spend into Other. Export Analytics when you review the changelog: spending trend, category breakdown, merchant ranking, and status mix show whether the policy is biting the right places.

If your chart of accounts work is still messy, fix naming there first so Expense categories can mirror it. See Best startup financial planning tools for founders when you decide where budgets and expense tracking live alongside policy rules. Expense policy for startups that references category names nobody uses in the product will force submitters to guess.

Illustrative thirty-day rollout

Illustrative Nova rollout (composite only): Week 1: write the one-pager; announce hard no list. Week 2: add Policy Rules for alcohol block and meals warn; train submitters on inline warnings. Week 3: flip meals to block; require Description customer tags for entertainment. Week 4: export Analytics, review top merchants, adjust one cap with a dated changelog.

Illustrative miss to avoid: adding twenty Policy Rules on day one with no training. Submitters bypass with wrong categories. Start with two bright lines.

Scan-a-bill can suggest category and amount from a receipt image; humans still confirm purpose against the policy. A clean scan does not legalize a blocked merchant class.

Illustrative training agenda for Nova (composite only): fifteen minutes on the one-pager; five minutes clicking Add Expense and hitting a warn on a fake alcohol Description; five minutes on where Approvals show up when a background rule needs a human yes. Record the session once. New hires watch it before they receive a company card. Expense policy for startups without that loop turns Policy Rules into surprise errors.

Mileage and per-diem entries still need the same purpose discipline. Distance, rate, and trip dates belong in Mileage & Per-Diem; the one-pager should say whether personal car miles require a trip purpose in Description and whether alcohol still sits on the hard no list during travel days.

Exceptions, approvals, and the changelog

Exceptions need a named Approver and an expiry date. "Just this once" without a date becomes permanent. Store exceptions in the same Note as the policy.

Approval chains route submissions when configured. Policy Rules catch violations before save; approval chains catch spend that is allowed only with a human yes. Keep both. Do not ask Policy Rules to replace manager judgment on ambiguous travel.

Update the policy when cards, headcount, or customer entertainment norms change. Date every edit. Expense policy for startups that never versions will be quoted selectively in the next dispute.

Publish the one-pager where cardholders live. Link Policy Rules as the enforcement layer, not as the only copy of the rules. When Nova's next dinner hits a block, the submitter should already know why.

Measure success monthly: count of blocked submits, count of warning overrides if you allow them, and Other-category spend share. If blocks are high and training is low, teach before you tighten. If warnings never convert to cleaner submits, switch those lines to block.

Expense policy for startups is finished when a new hire can predict a block without pinging finance, and finance can point to Policy Rules that match the one-pager sentence for sentence.

Keep a short FAQ under the one-pager: personal cards versus company cards; tips and tax; team offsites; home-office peripherals; client gifts. Answer each in two sentences and point to the clause number. Link related ops hygiene such as Manage a startup without 15 tools when expense tools multiply and policy gets ignored across tabs. Policy clarity plus runway habit beats either alone.

Counsel disclaimer again: local employment and tax rules may require handbook language this post does not cover. Use counsel for that layer. Use the one-pager and Policy Rules for day-to-day spend control.

Tie major policy changes to the same week you edit budgets in Expenses. A lower meal cap with an unchanged entertainment budget confuses managers. Announce both. Keep the changelog in the policy Note with who approved the edit.

If contractors use personal cards for reimbursement, say whether Policy Rules still apply and how receipts enter Expenses. Unclear contractor paths are how alcohol and personal items re-enter through a side door. Spell the path once.