Getting a PocketBooks ledger out of the phone it lives on

Every figure PocketBooks holds — a logged expense, the category it was filed under, the budget it counts against — sits in a store on the account holder's own phone, copied out to a Google Drive backup and a local backup file. Nothing routes through a bank. That one fact settles the whole route: reaching this ledger is a data-extraction job over files the user already owns, not a request sent to some upstream institution. Sadr Soft, the developer, distributes the app through Google Play and the CafeBazaar store, and its description is plain about the surfaces — income and expense entries, categories, budgets, multi-currency support, financial goals, and the dual backup that mirrors all of it.

The bottom line for an integrator: PocketBooks is a client-side ledger, so the work is decoding the backup the app writes and, where a project needs more, reading the live store on a consenting device. For most jobs we start from that backup, because it is the one surface PocketBooks itself maintains as a portability feature and it survives version bumps better than the raw on-device schema. The device-store read is what we add when a project wants fields the backup drops, or data fresher than the last save.

Three routes into a PocketBooks ledger

These are the routes that genuinely apply to a manual money manager with on-device storage and a cloud backup. Access and onboarding are arranged with you during the project; the build runs against a sample backup or a consenting device, whichever fits.

Backup-file parsing

The Google Drive backup and the local backup file are the app's own export of the full ledger. We take a sample backup from the consenting account holder, decode its structure — these apps almost always ship a SQLite store, confirmed during the build — and write a parser that emits every transaction, category, budget and goal. Reachable: a complete snapshot at the moment of the save. Effort is low to moderate; durability is high, because the backup format is the part a vendor changes least often.

On-device store extraction

When a project needs the live state, or fields that a backup compacts away, we read the app's own data directory on a device or emulator the user controls. Reachable: the current ledger, including anything the backup normalizes out. Effort is moderate, durability medium — the on-device schema can shift between app versions, so we pin the parser to an observed version and watch for drift.

Scripted retrieval of the cloud backup

For a recurring sync rather than a one-off pull, we script collection of the backup from the account holder's own consented Google Drive folder, then run the same parser. Reachable: each new backup as the app produces it, on a schedule. This is the route that turns a one-time export into a feed you can call on a cadence.

What the app stores, field by field

What lands in your repository

The work ships as code and documents tied to these exact surfaces, not a generic toolkit:

• An OpenAPI/Swagger spec describing the ledger as endpoints — list transactions, fetch categories, read budgets and goals — so the export looks like an API even though the source is a backup file.
• A protocol and decode report: the backup format, the SQLite table and column layout as observed, and how the Drive backup and local backup differ.
• Runnable source for the key reads, in Python or Node.js, with the currency-normalization step built in.
• Automated tests that run a known sample backup through the parser and assert the row counts and totals.
• Interface documentation plus data-retention guidance — what we keep, for how long, and how a deletion request flows through.

A backup parse, in code

Illustrative — table and column names are confirmed from a sample backup during the build, since a manual money manager stores its ledger locally rather than behind a login. The shape is what matters here.

import sqlite3, json

def read_ledger(backup_path, base_currency="USD"):
    db = sqlite3.connect(backup_path)
    db.row_factory = sqlite3.Row
    try:
        rows = db.execute("""
            SELECT t.id, t.amount, t.currency, t.type,   -- income / expense
                   t.note, t.created_at,
                   c.name AS category
            FROM   transactions t
            LEFT JOIN categories c ON c.id = t.category_id
            ORDER BY t.created_at
        """).fetchall()
    except sqlite3.OperationalError as e:
        # a new app version moved the schema -> flag, do not guess
        raise SystemExit(f"schema drift, re-map needed: {e}")
    return [normalize(dict(r), base_currency) for r in rows]

def normalize(r, base_currency):
    sign = 1 if r["type"] == "income" else -1
    return {
        "id":        r["id"],
        "booked_at": r["created_at"],
        "amount":    sign * abs(r["amount"]),
        "currency":  r["currency"] or base_currency,
        "category":  r["category"] or "uncategorized",
        "memo":      r["note"],
    }

The shape we normalize to

Whatever the on-disk layout turns out to be, the export settles into a stable shape so downstream systems don't track app internals:

{
  "transaction": {
    "id": "string",
    "booked_at": "ISO-8601",
    "amount": "signed decimal, minor-unit aware",
    "currency": "ISO-4217",
    "category": "string",
    "memo": "string | null",
    "account": "string | null"
  }
}

Consent and the data-protection picture

No regulated open-banking scheme governs this work, because PocketBooks does not pull from a bank — there is no third party's data in the file, only the account holder's own entries. The dependable basis is therefore that person's authorization over their own records, recorded before any extraction runs. Where an EU resident's data is in scope, GDPR principles apply directly: we minimize to the fields a project needs, honor deletion, and keep a consent log. Google's own Data Safety framework frames the same expectation at the store level — that data collection and sharing are disclosed and that users get a path to delete what is held. We work to that posture: authorized access, a documented decode, data kept only as long as the engagement requires, and an NDA where the client wants one.

Things the build accounts for

Two details on this app shape the engineering, and we handle both on our side.

Multi-currency is first-class here, so a transaction can carry a currency that differs from the next one. We read each entry's own currency and the app's base-currency setting, and emit both the original and a normalized figure — a consolidated total is never produced by silently summing across units. Second, the app updates regularly (CafeBazaar lists version 5.6.6, last updated May 2025), and a version bump can move the backup schema. We pin the parser to the version we mapped and keep a small schema-diff check, so a changed backup is caught and re-mapped before it can corrupt a sync rather than after. Access is arranged with you at the start — a sample backup, or a consenting device for the live read — and the local backup and the Drive backup are reconciled so the two never disagree about a total.

How fresh a synced copy stays

A backup is only as current as the last time the app wrote one, and that cadence is the user's to set. For a near-live copy we read the on-device store directly; for a scheduled feed we collect each new Drive backup as it appears. Either way we checksum the snapshot, so an unchanged ledger is recognized and skipped instead of re-imported. That keeps a daily or weekly sync cheap and quiet.

Screens we mapped

The interface surfaces above were read against the app's own published screenshots.

What we read, and when

This mapping was put together in June 2026 from the app's own listings and Google's store-level data guidance. We checked the Google Play page for the feature set and developer, the CafeBazaar listing for version and update history, and Google's Data Safety documentation for how store-level disclosure is meant to work. Where the app's internal storage details are not public, we say so and confirm them against a real backup during the build rather than guessing.

• Google Play — PocketBooks - Money Manager (Sadr Soft)
• CafeBazaar listing — version and update history
• Google Play — understanding the Data Safety section

Mapped by the OpenBanking Studio integration desk · June 2026.

Other money managers in the same orbit

An integrator standardizing personal-finance data usually meets several of these alongside PocketBooks; the data they hold rhymes, even when the storage does not.

• Monefy — a fast tap-to-add expense tracker; per-entry amounts and category icons, local and cloud sync.
• Wallet by BudgetBakers — accounts, budgets and bank-import features; a richer record set per user.
• Spendee — shared wallets and travel budgets; transactions tied to wallets and members.
• Bluecoins — strong in-app currency conversion; detailed transaction and account tables.
• Money Manager (Realbyte) — double-entry style accounts with Excel and backup export.
• Goodbudget — envelope budgeting; allocations and transactions per envelope.
• Money Lover — categorized spending, budgets and bills across accounts.
• AndroMoney — a long-standing Android tracker with multi-account and cloud backup.

Questions integrators ask about PocketBooks

Does PocketBooks keep my data on Google's servers or just on the phone?

It lives in an on-device store and is copied out to a Google Drive backup and a local backup file, both owned by the account holder. Extraction works from those copies, with the account holder's consent. No bank or upstream institution sits in the path.

We log spending in three currencies — how does that survive an export?

Each entry carries its own currency, and the app has a base-currency setting. We read both and emit the original amount plus a normalized amount, so a consolidated report never quietly adds dollars to euros.

How current can a synced copy of a PocketBooks ledger be?

As fresh as the most recent backup the app has written. When a project needs it closer to live, we read the on-device store directly and checksum each snapshot so an unchanged ledger is not pulled twice.

Which data-protection rules apply when the developer is outside the US and EU?

The dependable basis is the account holder's authorization over their own records. Where an EU resident's data is involved, GDPR principles — data minimization, deletion on request — guide what we keep. We log the consent and retain only the fields a project actually uses.

Source delivery starts at $300, billed only after the parser, spec and docs are in your hands and you have run them against your own backup. The same reads can instead run as a hosted endpoint you call and pay for per request, with nothing owed upfront. Either way the cycle is one to two weeks. Tell us the app and what you want out of its ledger, and we handle the decode, the access arrangements and the compliance side — start at /contact.html.