Finance · App Starter
Receipts to reports to reimbursement, with policy limits enforced along the way — a full expense system in code your company owns.
Describe your expense policy — categories, limits, who approves what — and Dual7 generates this system to enforce it: submitted reports with receipt-backed line items, approvals that route by amount and department, and a reimbursement queue finance can clear in one sitting. The policy lives in your code, where you can read it.
01 · Data model
Expense chaos is usually schema chaos: receipts in one place, approvals in email, reimbursements in payroll notes. Six connected tables put the whole path — spend, evidence, decision, payout — in one queryable structure.
| table | what it holds |
|---|---|
employees | Submitters and approvers with department, manager, and default cost center — the fields approval routing reads from. |
reports | Bundles of expenses submitted together for a trip, month, or project, moving through draft, submitted, approved, and reimbursed states. |
expenses | Individual line items with amount, date, merchant, category, and attached receipt — the atomic unit everything else summarizes. |
receipts | Uploaded receipt images and files tied to their line items, so the evidence travels with the claim through every review. |
categories | Spend types — travel, meals, software, equipment — each carrying its policy limit, per-diem rules, and GL code mapping. |
approvals | Every approve, reject, and return-for-fix decision with actor, timestamp, and note — the trail that makes month-end defensible. |
02 · Screens
Each expense pairs an amount with its receipt at entry time, not at audit time. Missing-receipt items are flagged before submission, so the version finance sees is already complete — the back-and-forth over a lost taxi slip happens with the submitter, not the ledger.
Reports route by amount and department: a manager sign-off for routine claims, finance review above the threshold you set, and an optional executive step for exceptions. Approvers see line items with receipts inline, and a return-for-fix goes back with the comment attached.
Categories carry limits — per item, per day, per report — checked at entry, with over-limit items requiring a written justification to proceed. Policy enforcement stops being a memo people skim and becomes a rule the form applies.
Approved reports land in a payout queue grouped by employee and pay cycle, with amounts totaled and export-ready for payroll or banking. Marking a batch paid closes the loop, and every report shows when its money actually moved.
03 · Process
Categories, limits, approval thresholds, and who signs off at each level — in plain language. The starter turns your policy into schema and rules.
Add a mileage category with per-kilometer rates, a project field on line items, or a stricter path for travel — conversational changes that land as code you can review.
Deploy with approval gates and an audit trail onto your infrastructure. Spend records and receipts live in your database from the first claim.
04 · Fit
Photographed receipts arrive by chat, spreadsheets by email, and the question 'was this approved?' has no reliable answer. This starter replaces that with one queue, one trail, and totals that reconcile — the process you've been describing in the onboarding doc, finally enforced by software.
Expense platforms charge per active user per month, which stings when most employees file one report a quarter. Owning the system means occasional submitters cost nothing, and the subscription line item becomes a one-time build.
The first external audit or diligence process turns loose expense habits into findings. Standing up a system with receipts attached, approvals timestamped, and policy limits enforced is cheap insurance — and doing it in code you own means the controls mature with the company.
Field per-diems that vary by city, equipment purchases needing a second signature, client-billable travel with its own category tree — when your policy has real structure, generic tools flatten it. Here the policy is the input, and the system comes out matching it.
05 · Yours
Shape it to your ledger first: rename categories to match your chart of accounts, set the limits your policy actually specifies, and add fields — project codes, client tags, mileage rates — that your reporting needs. In Vibe mode these are conversational edits that keep schema, forms, and reports in sync.
From there it grows like any codebase you own: connect the reimbursement queue to your payroll export, add a corporate-card feed that pre-populates line items for matching, or build per-department spend dashboards on the same tables. The generated app is standard full-stack code with no runtime dependency on Dual7 — your accountant's wishlist becomes a backlog, not a vendor petition.
Expense SaaS holds your spend history — the record of where every reimbursed dollar went — behind a subscription, and its pricing scales with the headcount you're trying to grow. This starter puts the whole system in your repository: the policy rules are readable code, the receipts and approvals are rows in your database, and no vendor sits between finance and its own records.
You take on operating the app, and the governed pipeline is designed to keep that responsible: changes gate through approvals, the audit trail covers the system as well as the spend, and regeneration handles the day your policy gets restructured rather than amended.
06 · Industries
Every expense coded to a client and engagement, billable or not — expense tracking built for firms, in code the firm owns.
Every dollar coded to its fund, grant, and function at the moment it's spent — expense tracking your nonprofit owns.
Six connected entities — employees, reports, expenses, receipts, categories, approvals — plus receipt-backed line-item entry, multi-step approval routing, category policy limits with justification flows, and a reimbursement queue. All generated as source code your company owns.
Yes. Routing reads manager relationships, departments, and the amount thresholds you describe, and the rules are explicit code — so a reorg or a new threshold is an edit you can review and test, not a configuration excavation.
Limits live on categories — per item, per day, or per report — and are checked when the expense is entered. Over-limit items require written justification before the report can be submitted, and approvers see the flag with the explanation beside it.
Receipts are their own entity, attached to line items at entry and carried through every approval view. Items missing receipts are flagged before submission, which moves the chase-the-receipt conversation to where it's cheap: before finance ever sees the report.
The reimbursement queue produces batch totals per employee and pay cycle, ready to export or integrate. Because you own the schema and code, wiring it to your payroll provider or accounting system is ordinary integration work with no API tier in the way.
The line-item model accommodates card-fed expenses alongside out-of-pocket claims — a card feed integration pre-populates expenses for employees to categorize and attach receipts to. It's a common first extension, built on tables you already have.
Dual7 App Starters
Receipts to reports to reimbursement, with policy limits enforced along the way — a full expense system in code your company owns. Describe your version to start — the output is a project you own.