Skip to main content
Documents lets you turn PDF statements and receipts into transactions when Redbark does not support your bank or brokerage as a live connection. You create a bucket, add files (by upload or by email), and Redbark extracts the transactions for you. Once extracted, a bucket behaves like any other connection. You can add it to a sync to deliver its transactions to your destinations, and you can query it through the API and MCP server, in exactly the same shape as a bank connection. In other words, Documents is an alternative to a connection for accounts our providers do not cover yet (for example Australian American Express cards, see Connections).

​
How Documents differs from a bank connection

This is the important distinction. Bank and brokerage connections are pass-through: transactions are fetched from the provider at sync time and written to your destination, not kept as a permanent ledger in our primary database or logs. Banking reads can use a bounded encrypted cache; see Caching and Consents and data. Documents cannot work that way. There is no live provider feed to proxy, so to get your transactions we have to read the file you give us. That means Documents stores data that a normal connection never does.
Documents is not pass-through. To extract your transactions we store both:
  • The file you upload or forward, in encrypted object storage. We keep it as the provenance for the rows we extracted from it.
  • The extracted transactions, in our database, so they can be queried and synced. This includes the opening, closing and running balances printed on a statement, which are used for the balance check.
This is different from bank and brokerage connections, where files are not involved and provider transaction data is not stored in our primary database or logs. If that trade-off does not suit you, use a live connection instead where one is available.
Remove individual files from the bucket to remove their extracted rows and request deletion of their stored bytes. There is currently no delete-bucket control. Removing a Documents connection through the API does not erase its imported files and rows. File deletion does not remove rows already delivered to an external destination.

​
Buckets

A bucket collects related files and the transactions extracted from them. There are two types:

Statement

For an account at a bank we do not support. Add statement PDFs and the line items become transactions automatically.

Receipts

For tracking individual purchases. Add a receipt and it is captured as a transaction.
Behind the scenes a bucket is modelled as a connection with a single account, which is why it shows up alongside your bank connections in the API and can be added to a sync.

​
Adding documents

​
Upload

On a bucket, drag and drop files onto the upload area or click to choose them. Supported file types are PDF, PNG, JPEG, CSV, OFX/QFX/QBO, and QIF, up to 4 MB each. Structured exports (CSV, OFX/QFX/QBO, and QIF) go in Statement buckets. Receipts buckets accept PDF and image files only.

​
Email

Each bucket has its own forwarding address, shown on the bucket’s Settings tab (for example u_ab12cd34@documents.redbark.com). Forward an email to that address and Redbark extracts the document from it. This is handy for statements and receipts that already arrive in your inbox: in Gmail, for instance, you can set up a filter that auto-forwards them.
The document must be an attachment. Redbark only reads file attachments (PDF, PNG, JPEG, CSV, OFX/QFX/QBO, or QIF). Text in the body of the email itself is not extracted, so a receipt pasted into the email body, or an HTML email receipt with no attachment, will not produce any transactions.Nothing is dropped silently: if a forwarded email has no readable attachment, it still appears in the bucket as a file marked “received but unreadable” so you can see it arrived.

​
After extraction

Most extracted transactions are added to the bucket and sync to your destinations automatically, in the same format as bank transactions. There is no general manual-review step. Redbark checks each file before its transactions sync:
  • Balance check. Where a statement prints an opening and closing balance, or a running balance beside each line, Redbark checks that the transactions it read add up. The Files tab shows Balanced when they do, or how far out they are when they do not. A file that is out usually has a missing or misread line.
  • Direction. Where printed balances settle a line’s direction, Redbark uses it. A line that still could be either a charge or a refund is held until you choose, even if the statement prints balances.
  • Duplicates. A statement transaction that matches one already confirmed in the bucket from another file is skipped, so overlapping statements do not double up. Repeated lines within one file are not compared with each other. Receipt files do not use this cross-file transaction check.
  • Amount, date and currency. Ordinary low-confidence rows sync with a marker.

​
Transactions that need review

A held transaction does not sync until you pick a direction. The bucket shows how many are waiting, on the Documents page and at the top of the bucket. Open the bucket’s Transactions tab and choose Needs review. Select one or more rows, then choose Mark as money out for a charge or Mark as money in for a refund or payment. Use Discard for a row you do not want. Each row links to the page of the file it came from.

​
Skipped transactions

The Skipped view lists duplicates and rows you discarded. Choose Keep to sync a duplicate anyway, or Restore to return a discarded row to Needs review, where you must choose its direction before it syncs. Deleting a file restores one skipped copy of each transaction it supplied; any further duplicates stay skipped. Content flagged as suspicious is blocked from sync and cannot be released. If an extraction is clearly wrong, delete the file to remove its rows and upload a cleaner copy.

​
When a file fails

A failed file shows the reason on the Files tab. Common reasons are a file with no readable transactions, a password-protected PDF, and a statement too long to read in one go. Failed files never count against your allowance.

​
Retrying a failed extraction

Use Retry on a failed file when its original is still available. Uploading or emailing the same file to the same bucket also retries that failed document rather than creating another copy. A file already being processed or successfully extracted is treated as a duplicate. Re-extraction preserves the identifiers and values of already-confirmed transactions, including ones already delivered to a destination. It can refresh held rows and add newly found rows. Retrying is not a way to replace confirmed transactions with a different reading.

​
Limits

Reading a PDF, PNG, or JPEG uses an AI model. CSV imports also use a model to map columns, so successful imports of these formats count against your allowance. OFX/QFX/QBO and QIF parse without a model call and never count against it. The monthly AI-extraction allowances are:
Lapsed subscriptions (expired, cancelled, unpaid, incomplete, or paused) have no AI-extraction allowance, including grandfathered accounts. OFX/QFX/QBO and QIF remain unmetered.
A few things worth knowing:
  • You’re only charged for successful extractions. A document counts toward your allowance once it reaches the Ready state. Failed extractions, files with no readable transactions, and forwarded emails with no readable attachment never use a slot.
  • The allowance resets on the 1st of each month (UTC).
  • Each file can be up to 4 MB and 30 pages. Larger files are rejected before extraction. Split a long statement into parts if you hit the page limit.
  • Structured imports accept up to 10,000 transactions per file. Split larger exports into separate files.
If you reach your monthly allowance, uploading a metered file (PDF, PNG, JPEG, or CSV) is rejected on the spot with a clear error and the file is not recorded. A metered document forwarded by email is kept in the bucket as a visible failed item so you can see it arrived. Nothing extracts automatically when the allowance resets: you re-submit any documents you still want processed. OFX/QFX/QBO and QIF keep working even at the limit. Existing transactions and syncs are unaffected by exhausting the extraction allowance.

​
Using a bucket

​
With syncs

Add a bucket to a sync the same way you add a bank connection, then pick a destination. Its transactions are written to that destination in the same format as bank transactions. Uploading several months of statements and adding the bucket to a sync backfills that history automatically. If the bucket is already syncing, newly confirmed rows can still be delivered when their transaction dates are older than the normal incremental window. They must be on or after the sync’s Data From Date. This catch-up includes rows confirmed in the last 60 days; if older confirmations were missed, contact support about a full re-sync. Destination limits still apply, including YNAB’s five-year history limit.

​
With the API and MCP

A bucket appears in GET /connections and GET /accounts, and its transactions are returned by GET /transactions, in the same shape as transactions from a bank. Your AI tools see it through the MCP server the same way. A bucket is just another connection, but transaction reads use the same 30-day default window as banking reads. Pass from when you need older imported history.