ToolJovia
Files

OFX XML Statement Exporter

Export posted bank or credit-card transaction source rows from a selected local OFX 2.x XML file without changing amount, date or ID text.

✓ Browser-local processing
Files are read locally and are not uploaded.

Loading tool…

How to use OFX XML Statement Exporter

Recover a usable transaction table from your own downloaded statement while keeping account context and original source spelling visible. Bank and credit-card responses share one workflow. Repeated IDs and correction records stay separate, and excluded pending records are counted rather than silently blended into posted rows.

  1. Choose one actual local UTF-8 OFX XML file, or load the original example. This selected profile requires XML and OFX declarations and an unencrypted 2.x response.
  2. Run the source export. Review statement/account identity, exact posted-record strings, missing selected fields, repeated FITIDs, correction fields and excluded pending counts.
  3. Download full selected JSON evidence or a simpler posted-row CSV. Preserve the original file and verify any later accounting import, correction or operational decision yourself.

Good to know

  • One nonempty actual file of at most 300,000 bytes and 200,000 decoded UTF-16 code units. Strict UTF-8 is required; one leading BOM is accepted. This profile requires XML 1.0, an OFX declaration with all five attributes, OFXHEADER 200, VERSION 200/201/202/203/210/211/220/221/230 and SECURITY NONE. OFX 1.x SGML, encrypted files, MIME transport and malformed-file repair are unsupported.
  • Native detached XML parsing follows a separate lexical allocation guard: no DTD/entity declaration-like source text (including inside comments/CDATA) or unrelated processing instructions; at most 5,000 element starts and 32 levels. Supported elements must be namespace-free and attribute-free, with exact case-sensitive names. Foreign namespaces, duplicate selected singleton fields and unsupported message-set/wrapper shapes refuse the whole operation. This is not full OFX or XML-schema validation.
  • Only bank STMTRS and credit-card CCSTMTRS responses inside their respective message-set/transaction wrappers are selected. At most 10 statement responses and 1,000 posted STMTTRN records are accepted. Pending STMTTRNP records are counted, up to 1,000, but their details are excluded from the CSV and report. Signon payload values are not exported; this tool never connects to a bank or asks for account credentials.
  • Selected XML-decoded leaf text is kept exactly, including spaces, case, amount signs/decimal separators/zeros, date-time suffixes and identifiers. No Number conversion, date/timezone conversion, arithmetic, rounding, sign inference, exchange-rate conversion or balance reconciliation occurs. XML 1.0 resolves character references and normalizes source line endings; raw entity spellings and original byte offsets are not retained. Date, currency, amount and status contents are source evidence rather than validated financial values. A selected leaf is at most 2,000 characters.
  • Selected transaction fields cover type, posting/user/availability dates, amount, FITID, correction reference/action, server/check/reference IDs, name/extended name, memo and a PAYEE name. Declared CURRENCY/ORIGCURRENCY symbols and rates remain separate raw fields. Account context, period and selected ledger/available balance strings remain in JSON. Named unassessed aggregates are omitted, including investment/loan/detail/image semantics. This is a lossy selected export, not a complete OFX round trip.
  • Missing selected fields are explicit null/findings; an empty string stays distinct in JSON. Repeated exact FITIDs retain every source record and receive a repetition witness. Corrections are reported but never applied, and records are never merged or deleted. No identity, authenticity, account validity, complete statement, accounting correctness, tax or financial-advice claim is made.
  • Readable JSON and CSV are each capped at 1,000,000 characters. CSV repeats statement/account context per posted row and omits JSON-only findings; an empty posted list produces headers with the statement context still visible in JSON. Formula-like cells, including negative amount strings, are apostrophe-prefixed for spreadsheet exposure reduction. Original strings stay in JSON. Output may contain private account data; no upload, storage, source mounting, external fetch, automatic anonymization or redaction occurs.
  • Processing is local. Output is limited to 1,000,000 text characters unless a stricter file limit is stated.

Common questions

Will the exporter fix duplicate downloads, apply corrections or recalculate my balance?

No. It exports selected source evidence. Exact FITID repetitions remain separate, correction fields are visible but unapplied, and pending rows are excluded with an explicit count. Amounts and balances stay strings. Verify the original bank data and the behavior of any later accounting import independently.

Is this input sent to a server?

No. The application processes this input inside your browser tab and does not save it to persistent storage.

Keep going with related tools

All files →