Pulling a clean transaction ledger out of Money Tracker - Budget Keeper

Money Tracker - Budget Keeper writes each income and expense entry, its category and the budget figures into a structured store on the phone, the way its Play Store description frames the app — a fast recorder for daily spending rather than a bank-connected aggregator. That single fact decides the integration. The records an integrator wants are already complete and local; the work is reading them in a stable, documented shape, not chasing a remote endpoint. Where a build needs live balances on top of the manual ledger, that comes from the user's bank through a separate consented channel.

What the app holds, and what you'd do with it

The surfaces below come from the app's own feature description and the storage pattern common to this class of Android money manager, where a SQLite store is the working copy and a backup file is its portable mirror.

Routes that fit this app

Mapping the on-device store and backup file

This is where the complete picture sits. With the account holder's authorization, on their own device or from a backup they hand over, we read the store and its export format and document the field layout. Reachable: every entry, category and budget the user has recorded. Effort: moderate, mostly schema work. Durability: high, because the data model changes slowly between app updates. Access is arranged with you during onboarding — a consenting account or a sample backup is set up as part of the build, not asked for up front.

Native export ingestion

If the user can export from inside the app, that file is the quickest path to a first dataset. Reachable: whatever the export includes, often a flatter view than the full store. Effort: low. Durability: depends on the export staying stable. We treat it as a fast first cut and reconcile it against the fuller mapping.

Consented bank-data enrichment

The ledger here is keyed by hand, so it carries intent but not cleared-balance truth. When a project needs live balances and settled transactions next to it, we add an Account Information Services connection for the user's own bank under the open-banking regime in that market, and join the two on a shared schema.

For most builds the on-device mapping carries the project: it is the only source that holds the full, categorized history, and it does not depend on a network. We usually pair it with a native export for the first quick dataset, and reach for AIS only when a use case genuinely needs live bank movements rather than the user's own notes. Which combination is right gets settled against what you actually want out of the data.

What lands at the end

• An OpenAPI specification for a normalized read API over entries, categories and budgets.
• A field-mapping and format report for the on-device store and the backup file — types, units, the income/expense sign convention, date handling.
• Runnable source in Python or Node.js that reads a backup, normalizes it and serves or writes the result.
• A category-resolution module that keeps user-defined labels stable across renames.
• Automated tests over sample backups, including the multi-device duplicate case.
• Where AIS is in scope, the consent-flow report and token handling for the chosen open-banking provider.
• Interface documentation plus data-retention and minimization guidance.

A worked example

Illustrative, and confirmed against a sample during the build — field names are normalized to what the mapping report pins down for the specific app version, not asserted as the app's internal column names.

# Read a Money Tracker backup, normalize one entry, resolve its category.
# Field names below are placeholders resolved during the mapping pass.

import sqlite3
from datetime import datetime, timezone

def load_entries(backup_db_path):
    con = sqlite3.connect(backup_db_path)
    con.row_factory = sqlite3.Row
    rows = con.execute(
        "SELECT entry_id, amount_minor, kind, category_id, note, ts "
        "FROM ledger ORDER BY ts"
    ).fetchall()
    con.close()
    return rows

def normalize(row, category_map):
    sign = -1 if row["kind"] == "expense" else 1
    return {
        "id": row["entry_id"],
        "amount": sign * row["amount_minor"] / 100.0,
        "category": category_map.get(row["category_id"], "uncategorized"),
        "note": row["note"] or "",
        "occurred_at": datetime.fromtimestamp(row["ts"], timezone.utc).isoformat(),
    }

# de-duplicate across backups merged from two devices: key on (occurred_at, amount)
def dedupe(records):
    seen, out = set(), []
    for r in records:
        k = (r["occurred_at"], r["amount"])
        if k not in seen:
            seen.add(k); out.append(r)
    return out

The normalized record the API returns stays small and predictable:

{
  "id": "a91f",
  "amount": -12.40,
  "category": "groceries",
  "note": "weekly shop",
  "occurred_at": "2026-05-30T18:22:00+00:00"
}

Consent and the rules that apply

The dependable basis here is the account holder acting on their own data. The records live on a device the user controls, so the authority to read them is the user's own consent, captured and logged before any work touches real data. That holds regardless of market and does not lean on any single regulator.

Where a build adds live bank data, the applicable regime is whatever governs open banking in the user's country — in the UK, Account Information Services authorized by the Financial Conduct Authority under the Payment Services Regulations; in the EU, the equivalent PSD2 access; comparable schemes elsewhere. In all of them the consent is explicit, scoped to named data, and expires unless the user re-authorizes. For personal data more broadly we work to GDPR-style minimization where users are in the EU, and to the local data-protection law of the user's market. We keep access logs and consent records, minimize what is pulled, and sign an NDA where the engagement calls for one.

Engineering notes specific to this app

Two things shape the build here, and we handle both rather than hand them back as conditions.

• Backups reconcile by timestamp. When a user keeps the data on more than one phone, the backups merge on a last-write basis and can overlap. We de-duplicate on entry timestamp and amount at ingestion and log what merged, so a household editing on two devices does not get double-counted spending.
• Categories are user-defined, not a fixed taxonomy. Labels are free-form and can be renamed at any time. We pin each category to a stable internal code in a resolution pass, so a rename on the phone does not scatter history across new buckets downstream.
• The store layout can shift on app updates. When a new version moves or renames fields, the mapping can drift. We re-check the field mapping against a fresh backup as part of upkeep, so the API keeps returning the same shape after the app updates.
• Backup files may be encrypted. Where the export is protected, it is opened with the user's own credential during onboarding, kept inside the engagement, and never treated as something the customer must clear before we begin.

Interface evidence

Screens from the store listing, useful for confirming which figures and groupings the app actually surfaces. Tap to enlarge.

Similar apps in the same space

Other expense-and-budget trackers hold comparable records and come up when a project needs one schema across several apps. Names are listed for context, not ranked.

• Money Manager Expense & Budget (RealByte) — double-entry style ledger with accounts and categories, backed by a portable database file.
• Spendee — wallets per account plus optional bank connections, holding transactions and shared-budget data.
• AndroMoney — multi-account daily expense records with budgets and cloud backup.
• Financisto — open-source Android tracker with multiple accounts and exportable transaction data.
• Wallet by BudgetBakers — categorized transactions and budgets, with bank-sync in supported markets.
• Money Manager Ex — open-source app storing transactions in an AES-protected SQLite file synced via Google Drive or Dropbox.
• Fast Budget — expenses, budgets and recurring entries with CSV import on its web companion.
• PocketGuard — budgeting platform that links accounts and tracks spending against income.

How this was checked

Reviewed against the app's store listing and the storage pattern documented for this class of Android money manager, then cross-read against the open-banking consent rules that apply when a build adds live bank data. Mapped by the OpenBanking Studio integration desk, June 2026.

• Money Tracker - Budget Keeper on Google Play
• SQLite store and Storage Access Framework sync pattern (Money Manager Ex)
• FCA — Account Information Services and Payment Initiation Services
• Open Banking — Account Information Services consent guidelines

Questions integrators ask

Where does Money Tracker - Budget Keeper actually keep the entries we'd want to integrate?

Every income and expense entry, its category and the budget figures sit in a structured store on the device, the same data a user-enabled backup writes to a file. That store, or the backup file, is what we map under the account holder's authorization, not a remote feed we'd have to negotiate.

The categories in this app are custom and free-form. How do those survive the mapping?

We read the raw category records and build a mapping pass that pins each user-defined label to a stable code, so a category renamed on the phone still lands in the same column downstream. Income-versus-expense sign and the per-entry note carry through the same step.

Can the manual ledger be combined with live bank balances?

Yes. The on-device ledger is manual by design, so where you want live balances and cleared transactions alongside it we add a consented Account Information Services connection for the user's bank, governed by the open-banking regime in that market, and reconcile the two sources on a shared schema.

If a user keeps the backup synced across two phones, do we get duplicate records?

Backups of this kind reconcile by last-write timestamp, so two devices can produce overlapping files. We de-duplicate on the entry timestamp and amount during ingestion and keep an audit log of what merged, which matters when an account holder has been editing on more than one device.

You bring the app name and what you want out of its data; access and any compliance paperwork are arranged with you as the project runs. Then it goes one of two directions. Source-code delivery starts at $300 — you get the runnable mapper, the API spec, tests and the interface docs, and you pay after delivery once the result satisfies you. Or run it as a hosted pay-per-call API, where you call our endpoints and pay only for the calls with nothing up front. Either way the cycle is one to two weeks. Tell us what you need on the contact page and we will scope it.