Why a Reimbursed Expense Should Never Just Disappear

Once you've paid someone back for something they spent on the company, that record isn't a task anymore — it's history. It's the answer to "why does the books show ₹4,200 leaving the account on the 12th." It's what you pull up if a reimbursement gets questioned six months later. And it should behave like history: stable, findable, and not something a stray click can erase.

That sounds obvious when you say it out loud. But it's exactly the kind of thing that's easy to get wrong in the small print of how software handles state — which is why SparkyExpenses ties what you're allowed to do with an expense directly to where it is in its own lifecycle, not just to who you are.

What "delete" should mean for an expense

An expense goes through a real lifecycle in SparkyExpenses: it's logged, it moves to submitted, someone with approval rights reviews it, it gets approved or rejected, and — if approved — it eventually gets marked reimbursed once the payment has actually gone out. Each of those stages means something different for what should still be editable.

While an expense is sitting at logged or submitted, it's still in flux. Maybe the amount was a typo, maybe the category's wrong, maybe it turns out it wasn't billable to a client after all. Editing — and deleting, if it was a mistake to log in the first place — makes total sense at that stage. Nothing downstream depends on it yet.

Once it's approved, and especially once it's reimbursed, that's different. At that point the expense isn't a draft anymore, it's a receipt of something that actually happened: money left an account, a team member got paid back. Letting that record vanish afterward — even by accident, even with good intentions — would quietly break the trail that connects the expense to the payment. If someone reconciling the books later goes looking for it, there'd be nothing there. So SparkyExpenses locks editing and deletion the moment an expense reaches approved or reimbursed status. Only expenses still sitting at logged or submitted can be changed or removed.

Deleting an expense also removes its attached receipt from storage — which is exactly why that lock matters as much as it does. Losing an expense record after the fact wouldn't just be a missing row in a table, it would be the row and the proof it happened both gone, for money that had genuinely already moved.

Why this matters more for a small team lead than it looks like it should

Picture a small team lead who handles reimbursements for six or eight people, once a month, usually on a Friday afternoon between other things. They're moving fast: approve, approve, mark reimbursed, next. Mistakes in that kind of batch workflow aren't rare — someone fat-fingers a click, or opens the wrong expense's detail page and hits delete out of habit because they were just clearing out a duplicate two clicks earlier.

In that situation, the software's job is to be the thing that doesn't let a moment of momentum turn into a missing financial record. It's not about distrust of the person using it — it's that a monthly reconciliation process with real money in it shouldn't depend on nobody ever misclicking. The lock on approved and reimbursed expenses isn't friction, it's the app doing the part of "be careful" that a human reasonably can't do at 4:45pm on a Friday.

It also matters for the other side of the process — whoever originally logged the expense. If they could delete their own reimbursed expense, the person who reviewed and paid it would have no way to know that record might quietly disappear on them later. Locking it once it's reimbursed protects the whole chain, not just the approver's side of it.

How to do this in SparkyExpenses

Log an expense from the Expenses section, and if your organization uses departments or is billable to a client, fill those in along with the usual amount, category, and receipt. If your organization has approval workflows turned on, it goes straight into the approval queue — no separate submit step. An approver reviews it, approves or rejects it, and once approved, marks it reimbursed when the payment's actually gone out.

Up until approval, you can edit or delete freely — fix a typo, change the category, remove a duplicate. Once it's approved, and especially once it's reimbursed, the expense (and its receipt) is locked in place. If you need to correct something after that point, that's a conversation, not a delete button — which, for a financial record, is exactly how it should work.

You can see the full expense lifecycle and how approvals fit together on the SparkyExpenses features page.

The larger point

Software that touches money doesn't get to treat "delete" as a universal button. What's allowed has to depend on what state a record is in, and the further along that record is — the more real-world consequence it represents — the less it should be able to just go away. That's not a flashy feature. It's the kind of thing that only shows its value the one time you needed it and it was still there.