Concept — not a live product Independent verdict: VALIDATE FIRST

An inbox for financial evidence, not another dashboard

Before an alert becomes a record, make it answerable.

Money Inbox is a proposed review queue for transaction alerts, screenshots, PDFs, and manual notes. It keeps the evidence beside the fields you check—then lets you create an internal record or an internal shared-expense draft.

Try a review case Tell us how you track now
  • No money movement
  • No silent approval
  • No product is currently available
REVIEW ITEM MI / 0042

Source fragment

CARD PURCHASE
BERG CAFE   EUR 18.40
20 AUG · CARD • 2041

proposed record
Amount
−18.40 EUR
Merchant
Berg Cafe
Date
20 Aug 2026 check
Possible match
Same amount and card, one day apart.
PROPOSAL
NOT POSTED

A proposed interface—not a screenshot of working software.

The job under investigation

The record starts somewhere else.

A card alert lands in email. A receipt sits in Photos. A shared dinner is remembered in chat. To keep a reliable ledger, someone still has to interpret, retype, and check whether it was already entered.

01

Find the alert, screenshot, statement, or note.

02

Retype amount, date, merchant, account, and context.

03

Decide whether it is new, duplicated, pending, or posted.

04

Enter it into a spreadsheet, ledger, or group-expense tool.

What is known

This workflow is documented as a hypothesis, not observed behavior. There are no interviews, usage data, or proof that a separate inbox beats direct entry.

The proposed loop

One path from evidence to a decision you can inspect.

Capture → parse → normalize → deduplicate → review → post internally or draft → reconcile.

  1. A

    Bring one item

    Manual entry or an explicit share is the baseline. Mailbox access is not required for the concept test.

  2. B

    See the proposal

    Extracted fields stay linked to source evidence and uncertainty. Missing facts stay missing.

  3. C

    Resolve the relation

    Possible duplicates and pending-to-posted changes are suggestions, never silent merges.

  4. D

    Choose the effect

    Create an internal ledger record, save a draft, defer, or reject—with a history of the choice.

“Post internally” is a data-state change inside the proposed Money Inbox ledger. It never means paying, transferring, settling, or trading.

Interactive concept surface

Would this review earn the extra step?

Synthetic example · runs only in this page

Inbox / Review item MI–0042

Berg Cafe

Candidate · needs review
Source evidence
SYNTHETIC BANK ALERT

Card purchase
Berg Cafe — EUR 18.40
20 Aug 2026 at 08:14
Card ending 2041

Capture
Explicit share
Parser
Concept fixture v1
Retention
Not applicable—synthetic
Proposed fields1 field to check
Direction
Expense
Amount
18.40 EUR
Merchant
Berg Cafe
Date
20 Aug 2026 Low confidence
Account hint
Card • 2041

Possible lifecycle match
A manual entry for 18.40 EUR exists on 19 Aug. Compare before counting both.

Choose a conceptual outcome This changes only the explanation below.

This is a browser prototype. It does not parse files, create records, contact a bank, or send data anywhere.

Differentiation to test

Not breadth. A better chain of custody.

Broad finance apps already aggregate accounts, categorize transactions, and build dashboards. Spreadsheets and direct entry remain credible—and may be better.

The baseline The Money Inbox hypothesis
The destination row is the record. Evidence stays attached to the proposed field and later correction.
Duplicate checks are manual or import-specific. Duplicate and lifecycle relations are explicit choices with reasons.
Automation authority follows the app or script. Reads, proposals, and consequences are separate permission classes.
Lock-in depends on the chosen destination. Internal draft plus copy/export is the proposed fallback.

These are positioning hypotheses from desk research, not measured advantages or competitor performance claims.

Trust is a product surface

The narrowest useful authority.

The concept separates looking, proposing, approving, and acting. Source text is evidence—not an instruction. External services stay outside the core loop unless their permissions, terms, and recovery path pass separate gates.

Help test the boundary
P1

Read a queue summary

Small, typed metadata. No raw mailbox, database, filesystem, or provider token.

Later
P3

Prepare a reversible proposal

A draft is visibly separate from a record or externally posted expense.

Planned
P4

Approve one internal effect

Exact values, current version, human confirmation, and a receipt.

Planned
PX

Move money or grant general access

No transfers, trading, arbitrary SQL, shell, general HTTP, or autonomous external posting.

Never

Agent connectivity

MCP is a later, gated possibility—not the product wedge.

If the non-agent loop proves useful, a future MCP surface could expose narrow tools such as listing pending items, explaining possible duplicates, and storing a reversible proposal.

It would not expose unrestricted evidence, arbitrary queries, provider credentials, external posting, deletion, or money movement. Every consequential internal write would return to a first-party approval screen.

The next honest step

Help decide whether this should exist.

The critical question is not whether the interface looks plausible. It is whether reviewing evidence saves total effort and improves trust compared with entering the transaction directly.

Which evidence gets retyped today? Does provenance help during correction? Is this a ledger or an export bridge?
LOCAL VALIDATION NOTE No account · no network
Where do you record transactions now?
What evidence do you retype? Select any
What should Money Inbox be if validated?
Local prototype only.

Your choices are stored only in this browser using local storage so you can revisit them. No submission is sent, no owner receives a response, and clearing site data removes it.

Nothing on this page is financial advice. Money Inbox is not a bank, payment service, accounting product, fraud detector, or working application. The illustrated records and names are synthetic.