How can one transaction be recorded both in and out by mistake?

A generic transaction form, formula or auto-entry rule may apply both directions even when only one real cash movement occurred.

Why is this worse than a missing transaction?

Because the entry looks complete, so reviewers may not suspect the effect map itself is wrong.

How do you detect it?

Test each transaction type with a known example and compare the expected cash/platform effects with the real-world movement and provider statement.

Operational case file

Case File: One Transaction Hit Both Money In and Money Out

A single transaction created movements on both sides when only one cash direction and one corresponding platform direction were valid.

Field-derived caseDirection errorTransaction mapping

Evidence basisDuring testing, transaction mapping had to be corrected so entries did not automatically create both incoming and outgoing value in ways that contradicted the real transaction.

Why this error can be hard to see

The transaction is present in the register, so it looks documented. The problem is that the system applies an extra movement. Depending on the amounts, the duplicate direction may partially cancel another error or create an expected balance that no real cash count can match.

Use an effect map, not guesswork

Each transaction type should answer: What asset increased? What asset decreased? Did a receivable change? Where did the fee physically sit? Was a separate income classification created? If one of those questions has no real-world answer, the system should not invent a movement.

Example logic

Mobile-money cash-out

The business gives physical cash to the customer, so physical cash decreases. Under the configured provider model, the platform balance changes in the corresponding direction. The same physical cash should not also be recorded as an incoming cash movement merely because a fee or platform credit exists.

Shortage-forensics clue

If expected balances drift even though every transaction appears to be recorded, inspect the transaction effect map. A duplicated in/out effect can be more damaging than a missing row because it looks “complete.”

Control lesson

Define cash effect and platform effect for each transaction type.
Keep principal and fee effects distinguishable.
Do not let a generic auto-fill create both directions without a real event.
Regression-test transaction types against worked examples.
Compare expected balances with actual provider statements and cash counts.

The page explains the diagnostic principle; the app's internal transaction mapping implementation remains private.