The "Transfer Counted as an Expense" Bug That Breaks Almost Every Budgeting App

Muhammad Arslan — Sun, 09 Aug 2026 18:22:15 +0000

Move ₨15,000 from your bank account to a digital wallet. Nothing was
earned. Nothing was spent. Your net worth is identical to a second ago.

Open almost any budgeting app afterward and it'll cheerfully tell you that
you just "spent" ₨15,000.

I hit this constantly while building Danapani,
a multi-ledger personal finance app, and it turned out to be a genuinely
interesting data-modeling problem — not just a UI bug. Here's how the
transaction model actually works under the hood.

The naive model (and why it breaks)

The obvious first pass at a finance schema:

model Transaction {
  id        String   @id @default(uuid())
  accountId String
  type      TransactionType // INCOME | EXPENSE
  amount    Decimal
}

Every transaction either adds to a balance or subtracts from it. Simple —
until a user has more than one account. The moment money moves between
their own accounts, this model has no way to express "this isn't real
income or a real expense, it's the same money in a different place." So
it gets recorded as an EXPENSE on the source account, and your monthly
spending chart is now wrong.

The fix: a `TRANSFER` type with two linked legs

Instead of forcing a transfer through the income/expense lens, Danapani
treats it as a first-class type with two rows sharing a group ID:

model Transaction {
  id                  String   @id @default(uuid())
  userId              String
  accountId           String
  transferToId        String?
  type                TransactionType   // INCOME | EXPENSE | TRANSFER
  amount              Decimal
  transferGroupId     String?
  relatedTransactionId String?
  // ...
}

A single transfer becomes two Transaction rows, created atomically:

await prisma.$transaction(async (tx) => {
  const source = await tx.account.findUniqueOrThrow({ where: { id: sourceId } });
  if (source.balance < amount) throw new Error("Insufficient funds");

  const groupId = crypto.randomUUID();

  const outbound = await tx.transaction.create({
    data: { accountId: sourceId, type: "TRANSFER", amount: -amount, transferGroupId: groupId },
  });

  const inbound = await tx.transaction.create({
    data: {
      accountId: destinationId,
      type: "TRANSFER",
      amount,
      transferGroupId: groupId,
      relatedTransactionId: outbound.id,
    },
  });

  await tx.account.update({ where: { id: sourceId }, data: { balance: { decrement: amount } } });
  await tx.account.update({ where: { id: destinationId }, data: { balance: { increment: amount } } });
});

Two consequences fall out of this for free:

Reporting is correct by construction. Income/expense charts simply filter WHERE type != 'TRANSFER' — no special-casing needed downstream.
Deletes and edits stay consistent. Delete one leg, and the handler looks up relatedTransactionId and reverts both account balances together, instead of leaving an orphaned half-transfer.

The whole prisma.$transaction() block matters here — without it, a
crash between the two balance updates leaves one account short and the
other over, and now the user's money has silently duplicated or
vanished. Wrapping it means either both legs commit or neither does.

Isolating a user's own books from each other

The second problem: a single person can have very different reasons to
track money — personal spending, freelance client income, a small side
business — and mixing them in one view makes monthly reports meaningless.

Danapani solves this with a Ledger model that transactions optionally
tag into:

model Ledger {
  id       String @id @default(uuid())
  userId   String
  name     String // "Personal", "Freelance USD", "Business"
}

A transfer between a Meezan-style bank account and a wallet, tagged to
the same ledger, nets to zero on that ledger's report. Money moved
between ledgers (say, paying yourself from the business ledger into
personal) is still just a transfer — same mechanism, just crossing a
ledger boundary instead of an account boundary.

Multi-tenant isolation with Postgres Row-Level Security

None of this matters if user A can query user B's transactions. Rather
than repeating WHERE userId = ? in every single query by hand (and
inevitably forgetting it somewhere), the isolation is enforced at the
database layer:

ALTER TABLE "Transaction" ENABLE ROW LEVEL SECURITY;

CREATE POLICY user_isolation ON "Transaction"
  USING (user_id = current_setting('app.current_user_id')::uuid);

Every request sets app.current_user_id from the verified JWT before
running any query. Even a bug that forgets a WHERE clause in
application code can't leak another user's rows — Postgres itself
refuses to return them. For a finance app specifically, I wanted that
guarantee to not depend on every future engineer (including future me)
remembering to scope every query correctly.

Stack, if you're curious

Next.js 15 (App Router) · TypeScript · Prisma · PostgreSQL · Redux
Toolkit + RTK Query on the frontend, hitting the same
prisma.$transaction() pattern above for every mutation that touches
more than one row.

Try it / poke holes in it

Danapani is live and free at danapani.app if
you want to see the transfer/ledger model in action. I'd genuinely like
feedback from other people who've built financial or multi-tenant
systems — particularly if you've solved the double-entry problem
differently, or found a hole in the RLS approach above.

Why Your Profanity Filter Fails Against Unicode (And How to Fix It)

Muhammad Arslan — Tue, 24 Feb 2026 18:37:46 +0000

Most profanity filters only check raw input.

That’s the problem.

You can block fuck.

But what about:

fu\u0441k (Cyrillic “с” instead of Latin “c”)

ｆｕｃｋ (fullwidth Unicode characters)

f.u.c.k (separator bypass)

Fr33 m0ney (leet-speak)

fuuuuck (character stretching)

They all bypass typical word-list filters.

The issue isn’t your regex.
It’s the order of operations.

Normalize First. Validate Second.

Before checking profanity or spam, input should be normalized:

Unicode NFKC normalization
Zero-width character removal
Separator stripping
Homoglyph mapping
Leet-speak normalization
Repetition reduction

After normalization, all evasions collapse into a canonical form.
Then your profanity/spam logic actually works.

What I Built

I created @marslanmustafa/input-shield — a zero-dependency TypeScript validation package that:

Detects Unicode homoglyph attacks
Catches leet-based spam
Blocks stretched profanity
Detects gibberish (e.g. asdfghjkl)
Supports Zod integration
Validates HTML email content safely

Example:

import { createValidator } from '@marslanmustafa/input-shield';

const validator = createValidator()
  .field('Message')
  .min(2).max(500)
  .noProfanity()
  .noSpam()
  .noGibberish();

validator.validate('fu\u0441k'); 
// → blocked

Why This Matters

Unicode homoglyph attacks are not edge cases.
They’re easy, invisible, and widely ignored.

If you're validating user input in production, normalization isn’t optional. It’s required.

Links:

GitHub · npm

DEV Community: Muhammad Arslan