Read me first

If you have just been handed TallyCrux and you are wondering what it is and what to do with it, start here. This page assumes you work in finance, not software. Nothing below needs a technical background.

---

1. Who this is for

TallyCrux is for the person who owns employee expenses at a small or mid-sized company — typically a finance manager, a controller, or an office manager who inherited the job.

You are the right reader if your month currently involves chasing colleagues for photographs of receipts, deciding whether a dinner was reasonable, checking whether a card charge was ever explained, and then keying the result into an accounting package.

Three groups of people end up using it:

• Everyone who spends money submits expenses and attaches receipts.
• Managers approve or reject what their team submits.
• Finance sets the rules, reviews what the system has flagged, pays people back, and reports on the whole thing.

It is aimed at companies of roughly fifty to five hundred people, and it was built with non-US companies particularly in mind — VAT reclaim and multiple legal entities are treated as normal, not as an afterthought.

---

2. What it does

It takes an expense from the moment it happens to the moment it is paid and booked, and it removes most of the manual checking in between.

An employee photographs or forwards a receipt. The software reads it and pulls out the merchant, the date, the amount and the currency. It matches that receipt to the matching card transaction. It checks the expense against your company's rules and says whether it complies. A manager approves it. Finance pays it, and the record goes to your accounting system.

Alongside that, it watches for the things that quietly cost companies money: the same receipt claimed twice, a large expense split into smaller ones to slip under a limit, spending patterns that do not match a person's history, and — a newer problem — receipts that were never real, generated by an image model.

---

3. The domain

Expense management sits between the people who spend money and the accounts that record it. A few realities shape everything in this product.

A receipt is evidence, not data. Tax authorities care whether you can produce the document behind a claim. That is why receipt images are stored and kept beside the figures taken from them, rather than being discarded once the numbers are typed in.

Rules are company-specific and change often. Every company has its own view on what a reasonable hotel costs, who may approve what, and which categories need extra evidence. In most software those rules live in configuration that only IT can safely change.

Tax rules are not optional. In the EU, VAT paid on business expenses can often be reclaimed, but only with correct documentation. In the US, expense arrangements have to satisfy "accountable plan" rules or reimbursements become taxable pay. Many companies also pay a fixed daily allowance — a per diem — instead of reimbursing actual costs, and the acceptable rate depends on where the person was.

Companies are rarely one company. A group typically has several legal entities, often in different countries and currencies, that must be reported both separately and together.

Expense fraud is ordinary, not exotic. Most of it is small, repeated, and opportunistic — duplicate claims and inflated amounts rather than dramatic theft.

---

4. Where it fits

TallyCrux does not replace your bank or your accounting system. It sits between them.

• Your people use it directly, through a web browser.
• Your bank or card provider supplies the feed of card transactions, so spending appears without anyone typing it in. It is deliberately not tied to any one card programme — the point is that you keep your existing banking relationship.
• Your accounting system receives the approved, coded result. QuickBooks, Xero and Sage are the systems it is built around.
• Your identity provider can be used for sign-in, so people use their existing company login, and staff can be created and deactivated automatically when they join or leave.
• Your email can be pointed at it, so people forward receipts from their inbox.

One honest caveat about those connections. The workflow around them is complete and working — transactions are matched, approvals are enforced, accounts are coded, and syncing is recorded so nothing is sent twice. But the live connections to Plaid and to the accounting vendors are built as connection points awaiting credentials and final wiring, and the demo runs on a simulated bank feed rather than a real one. Reading receipts is a genuine AI integration and works against a real service. Treat the bank and accounting links as the first thing to commission, not as something already plugged in.

---

5. First run

The fastest way to understand TallyCrux is to look at it full of data before you put any of your own in.

There are two ways to do that, and both use the same sign-in details:

	What it is	How you learn the credentials
Hosted demo	The "Try the demo" button on this project's page at wbsp.ai. Nothing to install.	The sign-in screen shows them on itself.
Local preview	One command on your own machine (see useful-commands.md).	Printed in the terminal when it starts.

email:    admin@acme.test
password: TallyDemo!2026

There is no company or workspace field to fill in, and no "Sign in with Google" button — a password is the only way into a demo.

Either version contains a fictional company, Acme, with well over a hundred expense reports, several hundred receipts, card transactions, fraud alerts and two European subsidiaries. (Lists show the first hundred, so a total on screen is a page, not the whole set.) Nothing else needs installing — no database, no accounts, no setup.

Spend twenty minutes clicking around. Start on the overview, open a report, look at a receipt and what was read from it, then look at the fraud queue.

Both are throwaway: the hosted one is deleted a few minutes after you launch it, and the local one forgets everything when it stops. You cannot break either, so experiment freely.

Do this before anything else. Almost every decision in the next section is easier once you have seen what the finished thing looks like.

When you are ready to use it for real, your company is created once by a setup command that takes your company name, your first legal entity and the email address of your first administrator. That command refuses to run twice, so a live system can never accidentally end up serving two companies. Everything after that is done in the browser.

---

6. Setting up

Work in roughly this order.

1. Create the company and the first administrator (the step above). Sign in as that administrator.
2. Add your legal entities. If you are a group, add each company that files its own accounts. Every expense belongs to one of them, which is what makes the consolidated reporting meaningful later.
3. Add your people, and give each one a role. Roles are covered below. Do this before rules — approvals need somebody to approve.
4. Set up categories and how they map to your accounts. This is the translation between "taxi" and the account code your bookkeeper expects. Reports cannot be sent to your accounting system until a category has a mapping, and the system will tell you which one is missing rather than guessing.
5. Write your policies. You can build rules from conditions and limits, or simply write the rule as a sentence — "meals over seventy-five dollars per person need manager approval" — and let the software turn it into something it can enforce. It shows you its interpretation before you accept it, and you can preview a new policy against your recent expenses to see what it would have caught before it affects anybody.
6. Connect the card feed so transactions arrive on their own.
7. Connect your accounting system so approved reports flow onward.
8. Optionally connect sign-in and staff provisioning to your identity provider, and set up receipt forwarding by email.

Steps 6 to 8 are the connection points noted above; expect to involve technical help, and expect them to need credentials from the relevant provider.

---

7. Day to day

For the people spending money. Photograph a receipt, or forward it from email. Group expenses into a report, add a business purpose, and submit it. The business purpose matters more than it looks — "travel" is not something an auditor can accept, and a project or client reference is what makes a claim defensible a year later.

For managers. Open your approvals queue, look at what is waiting, and approve or reject with a comment. The comment is kept permanently with the report.

For finance. A typical week looks like this:

• Clear the exceptions on the card feed — the transactions the software could not match to a receipt on its own. This is intended to be a short list.
• Work the fraud queue. Each alert has a severity, a confidence score, and the evidence behind it, including how the people and expenses involved are connected. You assign it to yourself, decide, and record the outcome: confirmed, dismissed, or a false positive. The software raises the question; a person always answers it.
• Pay approved reports. They are gathered into payment batches for the bank.
• Send approved reports to your accounting system.
• Look at the analytics when something surprises you — spending by category, the trend month over month, budget against actual, and recurring charges, which is where forgotten subscriptions show up.
• Ask a spend question in plain language if the standard reports do not cover it. Worth knowing how this one works: the AI never writes a database query itself. It translates your question into a restricted, pre-approved shape, which is checked before anything runs and refused if it does not fit — so an unanswerable question comes back as "I can't answer that" rather than a confident wrong number. It needs to be switched on with an AI key; without one it simply reports itself unavailable.

---

8. Ongoing care

Monthly. Reconcile the card feed so nothing is left unmatched. Export the VAT reclaim report if you reclaim VAT. Send everything approved to your accounting system before you close the month.

Quarterly. Re-read your policies. They drift out of date faster than anyone expects, and the preview feature makes it safe to test a change before applying it. Review who has which role, especially for people who changed jobs internally.

Yearly. Check the per-diem rates you rely on, since published rates change. Confirm your expense arrangement still satisfies the tax rules you are claiming under.

Continuously, and this one matters. Make sure somebody is backing up the database and the stored receipt images, and make sure that backup has been tested by restoring it. The receipt images are evidence: losing them is not an inconvenience, it is a loss of the documentation behind claims you have already made. The preview version deliberately throws its data away when it stops, so never treat the preview as somewhere to keep anything.

When someone leaves, deactivate them rather than deleting them, so their history stays intact. If someone exercises a data-protection right, the software can produce everything held about a person, and can erase them in a way that anonymises the person while leaving the financial record standing.

---

Who can do what

Four roles, and the menu changes to match:

Role	What they can do
Submitter	Their own expenses, receipts and reports. Nothing else.
Manager	The above, plus approving what is routed to them.
Finance	The above, plus policies, the fraud queue, reimbursements, compliance, analytics and consolidated reporting.
Admin	Everything, plus provisioning and staff management.

People only see what their role allows — the finance sections are not merely hidden from a submitter, they are refused.

---

The demo data, and starting fresh

The preview contains a fictional group: Acme, with European and EMEA subsidiaries, well over a hundred expense reports across every stage from draft to paid, several hundred receipts with real images, a simulated bank feed, fraud alerts of several kinds, and one administrator account.

None of it is real, and none of it survives. The preview keeps everything inside itself, so stopping it discards the lot and starting it again gives you a clean copy of the same fictional company. That makes it safe to experiment with: you cannot break it permanently.

To start fresh for real use, do not use the preview at all. Use a proper installation and run the one-time company setup described under First run.

---

A short glossary

• Accountable plan — a US tax arrangement under which reimbursements are not treated as taxable pay, provided expenses are documented and substantiated.
• ACH — the US bank system for moving money in batches, used here to pay people back.
• Consolidation — combining the figures of several companies in a group into one view.
• GL code / general ledger — the account in your bookkeeping that an expense belongs to.
• Legal entity — a company that files its own accounts. A group has several.
• OCR — reading text out of an image, such as pulling the total off a photographed receipt.
• Per diem — a fixed daily allowance paid instead of reimbursing actual costs.
• SCIM — a standard that lets your staff directory create and deactivate user accounts automatically.
• Synthetic receipt — a receipt image generated by software for something that never happened.
• VAT reclaim — recovering the VAT paid on business expenses, where the rules allow.

---

The other documents here

Document	What it is for, and who should read it
getting-started.md	The next thing to read. A fuller tour, including running it yourself.
useful-commands.md	For whoever runs the software: starting it, loading demo data, deploying.
api-reference.md	For developers connecting another system to it.
openapi.yaml	The precise technical definition of that interface. Not for reading.
testing.md	How the software is tested — worth skimming if you need confidence in it.
web-ui.md	For developers changing the look of the screens.

---

Common questions

Do we have to change our corporate card? No. That is the point. It is built to take a feed from whatever card you already use.

What happens if the receipt reader gets something wrong? The original image is kept beside the extracted figures precisely so a person can check and correct them. Nothing is accepted purely because the software read it.

Can it approve or reject on its own? No, and this is deliberate. It decides, flags and recommends; a person makes the decision, and the decision is recorded against their name.

Why does a report show two currencies? Because that is what happened. It keeps amounts in the currency they occurred in, and it will not combine currencies into a single total without an exchange rate. A figure is either right or it is not shown.

It looks plain. Is that a bug? No. This is the working core, deliberately unbranded — no colours, logo or wording of yours. That layer is intended to be added, and it is the easiest part to change.

Why is my approvals queue empty in the preview? Because every demo report has already been decided. It is showing you the truth.

---

Where to get help

This application was generated by AI, and it is meant to be shaped further — whether that is your branding, a rule your industry needs, or an integration nobody has written yet.

Come to wbsp.ai. You can ask questions, suggest what this should do next, and find people who can turn it into something bespoke for your business. While you are there, look through what the community has already built — there are many versions of this application and many others besides, and one of them may already fit you better than you would expect.