Document handling

Privacy: your statement is yours

A bank statement is among the most sensitive documents you own. There is one path, it is the same for every file, and this page says exactly what happens on it.

The free preflight: RowSure server only, no AI

Select a statement on the app and your browser sends one temporary copy over HTTPS to RowSure's own application server. We parse it in memory to read what the document says about itself — how many pages it claims, how many statements it contains, its currency, whether it has a text layer and how many transactions it declares. It is not written to disk, not sent to Google or any other external service, and the bytes are discarded when that request ends. The preflight never looks at a single transaction amount.

Only if you then ask for the full conversion are rendered statement pages sent to the paid vision API described below.

The conversion: processed once, deleted immediately

To read the transactions we render the pages and send them to a vision API. For every file, without exception:

• The file is used only to produce your conversion
• The PDF is deleted the moment extraction finishes — not on a schedule, not at the end of the day
• Excel, a five-column transaction CSV and a separate diagnostic Verification CSV are produced for every deliverable ledger; QBO and OFX exist only for a green VERIFIED result. The files actually produced are kept up to one hour after payment (unpaid previews up to 24 hours), then permanently deleted — by a scheduler that doesn't depend on traffic
• A requested result link contains a random access capability. RowSure first tries to bind it to a signed browser session and remove it from the visible URL; if session cookies are blocked, it stays in the URL so the result remains accessible and the link must be treated as a secret
• Nothing you upload is used to train AI models — we run on the provider's paid tier, where the terms exclude it
• We never ask for your online banking credentials, and there is nothing to connect: RowSure reads a file you already have

The page that binds is the one inside the product. app.rowsure.com/privacy describes what the running instance actually does, including the one case where a document is kept: a statement that didn't convert, sent to us deliberately, deleted within 30 days or on request. This page explains the model; that one reports the configuration.

What we do not claim

Several converters advertise that your file “never leaves your browser”. We looked hard at building that, and we are not going to — so we would rather say why than leave a roadmap on this page that never ships.

An in-browser parser reads the PDF's font encoding instead of the page. On real statements that encoding is often wrong: the case that started this product was an Italian bank whose broken font made a parser read 166.98 where the page printed 4,166.98 — a silent error of €4,000 in a spreadsheet that looked perfect. We tested a deterministic parser against our own corpus and it reconciled none of those documents. A local mode that quietly gets the numbers wrong is not a privacy feature; it is the failure this product exists to prevent, wearing a reassuring label.

So: one path, one promise, and the promise is about what happens to the file — deleted on completion, never used for training, and no third party beyond the ones named below.

Security & sub-processors

Files travel over TLS (HTTPS) to the RowSure application hosted by Render Services, Inc. The uploaded PDF is deleted the moment extraction finishes; output files follow the retention schedule above. Render hosts the application and its temporary storage. Extraction then uses Google (Gemini API, paid tier — per the provider's terms, customer data is not used to train models) to read rendered statement pages. Both this site and the application sit behind Cloudflare, Inc. — DNS and network proxy — so your requests, uploads included, pass through Cloudflare's network on their way to the host. It is a carrier, not an analytics service: we send it nothing about you, and it is not given your documents to keep. What it does hold is what a network provider holds — request and traffic data, security and operational logs — under its own privacy policy. We would rather point you there than write “nothing is stored” on someone else's behalf. Payments are handled by Polar as Merchant of Record, so card details never touch our servers.

One more sub-processor exists, and it never sees the uploaded statement: Resend (Resend Inc., US) delivers access and purchase emails and a result email only when you request one. It also carries operator support, diagnostic and payment-recovery alerts. It receives the destination and message text; an operator alert can include the support/layout note you submitted, structural result context, a diagnostic reference/path or payment recovery category, but never the PDF itself. A requested result includes its bank, opening/closing balances and, for a red result, the computed closing balance, difference and first flagged row. If off-disk recovery is enabled, Resend also carries an encrypted, authenticated database attachment to the operator. The key is kept separately, so the attachment is not readable by the mail provider. It can contain private verification metadata, including original filenames used to label account-only case files, but Resend receives that only as ciphertext. It never contains the uploaded PDF or transaction rows. Delivery logs are kept for the shortest period its settings allow; no original filename is sent in readable form.

Every paid conversion creates a verification record at a random public URL. It stores the bank, period, opening and closing balances, transaction count, file fingerprint and, privately, the original filename used to label an account-only case file and the last four account digits used for continuity grouping, a pseudonymous licence link, extraction model and idempotent job-emission reference. The public page and downloadable record omit the original filename and account digits and never contain transaction rows. Records remain available until you ask us to delete them, so links already shared in a case file do not silently expire.

The durable record also keeps the verification state and internal reason, PDF-text match percentage, arithmetic/balance-exception and source-review row positions, any numeric-form occurrence shortfall and whether an independent second reading reproduced the same transaction amounts and balances. The public page and download omit the internal reason code but show the state and source-review diagnostics, so sharing the record cannot hide why verification was withheld.

Contact messages keep the email address, text and context deliberately submitted. Layout reports keep their timestamp, bank label, method, transaction count, result class and optional reply email, never a transaction value or document. These text records currently have no automatic expiry: they remain until the request is handled and removed, or until you ask us to delete them. A failed paid-delivery entry keeps the destination email, licence hash, plan and failure category in a local recovery journal. It remains in the operator's active queue until a signed one-time access link is successfully consumed; generating a link alone never marks delivery as resolved. The journal then adds the resolution time and keeps the resolved entry until it is removed manually or at your request; it has no automatic expiry today. It contains no access code, statement or transaction.

Short-lived abuse and delivery limits can keep the requesting IP address or the email address entered in a mail form, a timestamp and, where an exact retry or refund needs it, a random job reference. Their active windows are no longer than 24 hours; expired rows are removed on the next maintenance pass, normally within 15 minutes. They contain no filename, bank data, document or transaction. Temporary job state can also keep the original filename, an anonymous visitor's IP or a pseudonymous licence link for crash recovery alongside the short-lived result files described above. It expires with the job: one hour after a paid result or completed comparison, up to 24 hours for an unpaid preview. Neither rate-limit rows nor job directories enter recovery database snapshots.

The business database has local recovery snapshots on configured persistent storage. The current default rotates the most recent 14 daily snapshots; the binding privacy page inside the running product reports its configured window. A snapshot can contain accounts, purchase records, contacts and private verification-record metadata, but never an uploaded PDF or transaction rows. Temporary jobs, rate limits, check diagnostics and advertising attribution are excluded. Data removed from the active database can remain in an older local snapshot only until that snapshot rotates out. If optional off-disk recovery is enabled, an encrypted and authenticated snapshot is emailed on the configured schedule (seven days by default). An attachment already delivered cannot be edited selectively and follows the operator mailbox and Resend retention until deleted there. Recovery copies are used only for disaster recovery.

To prevent provider retries from emailing the operator the same payment alert repeatedly, RowSure keeps a SHA-256 fingerprint of the provider, event type, provider event ID and alert category for at most 30 days. It contains no email address, webhook payload or billing details.

With the same opt-in, a first-party link may carry a compact source label such as ref=producthunt. We count that label and whether the visit reaches the app, preflight, conversion or checkout. It is not tied to an IP address, email, document or browsing path, and no third-party analytics service receives it.

For each full check we also keep a pseudonymous operational result for up to 180 days: whether the upload was accepted at all (and if not, which limit refused it), whether extraction completed, whether the arithmetic reconciled or otherwise closed before a source check, input type, page and transaction counts, verification/proof/coverage codes, counts of repaired, balance-mismatch and PDF-source-review rows, numeric-form occurrence shortfalls, whether a second reading agreed, processing time, broad traffic source, whether the result page was opened, whether a price/file offer entered the viewport, whether its transaction preview was reached, whether a voluntary diagnostic copy was submitted, whether checkout was opened, whether Polar confirmed a paid order, and whether a document credit was spent on that result. Those stages share a random per-check reference not derived from a person, account, session, advertising click, job or file. It never contains a filename, bank, account, balance, amount, description, row position, document, IP address, email address or advertising click identifier. Check diagnostics and advertising attribution are excluded from recovery backups. If an opted-in ad visitor opens checkout from a result, the pending-checkout row temporarily holds both that random check reference and the click identifier. This marks that cohort's purchase; it does not add a file, bank, amount, IP address or email address to the diagnostics. The temporary association is deleted with the click attribution within 90 days.

A diagnostic document is kept only when you deliberately upload it again from the diagnostic form. It is deleted on request or within 30 days and used only to fix the layout. If that PDF is password-protected, RowSure stores a decrypted diagnostic copy so it can be inspected; the password itself is never retained.

Render's application log also records privacy-safe runtime events so we can see a live upload move through the queue: action type, a random temporary job ID where one exists, input class, technical counts and outcome. These structured action events never contain the filename, email address, bank, account, balance, amount, description or PDF contents, and follow the hosting log retention configured on Render. Separate delivery/support errors may identify the email needed to recover an account or purchase, but never include document contents.

There is no third-party analytics or advertising script, and we do not profile visitors. RowSure's own main.js contains the first-party advertising measurement described here, and it is opt-in. Before you select Accept, RowSure does not read or write advertising attribution in browser storage and does not add it to links or forms. We remember Accept or Reject for up to 180 days in the first-party rowsure_ads_consent cookie, shared only across RowSure subdomains. It contains the choice and its timestamp, not an advertising identifier. The prompt opens automatically only when the current URL contains a compact ad-click, ref or UTM value; direct and untagged organic visitors are not interrupted. The settings control remains available on every page.

If you accept after arriving from a search advertisement, the compact click identifier in the landing address can be kept in session storage while you move around this site and in a signed first-party cookie in the application. Its first-touch timestamp has an absolute 90-day limit: refreshing or navigating does not renew it. When checkout starts we keep the identifier with a separate random checkout reference; Polar receives only that random reference. Only a signed paid-order webhook creates an advertising conversion. The identifier is not copied into the diagnostic row; a pending checkout can temporarily associate it with the random check reference solely to measure check-to-purchase, never with an IP address, document, bank data, amount or browsing history. Use the Ad measurement settings control on any page to change your choice. Rejecting or revoking removes browser attribution and stops it being carried to another RowSure page or form.

Why we built it this way

Because the alternative is what the market already offers. Some competitors' homepages promise files "deleted automatically after conversion" while their privacy policies disclose third-party AI processing and retention windows measured in days. Don't take our word for it: read the policy, not the homepage — ours included. For an accountant uploading client data, that gap is the problem. We prefer a shorter promise we can keep.

Fixing an unsupported layout is opt-in

RowSure does not automatically retain your corrections or use them for training. If a statement does not convert properly, you can choose to upload that document again through the diagnostic form. That voluntary copy includes the values in the PDF, is used only to fix the layout, and is deleted on request or within 30 days, as described above.

Questions

Privacy questions get answered by a human: hello@rowsure.com.

Plain-language summary of our privacy commitments: the data controller is RowSure, reachable at hello@rowsure.com. We process the statements you upload and the email address you give us; payment data is handled by Polar, the Merchant of Record, and never reaches us. Retention: uploaded PDFs are deleted when extraction finishes, output files up to one hour after payment, unpaid previews and short-lived rate-limit/job-recovery state up to 24 hours (plus the next maintenance pass), pseudonymous check diagnostics up to 180 days, and local business-database snapshots under the rolling window described above. Sub-processors: Render Services, Inc. for application hosting and temporary storage; Google (Gemini API, paid tier — per the provider's terms, customer data is not used to train models); Cloudflare, Inc. as DNS and network proxy in front of the site and the application — your requests in transit, plus the traffic and security logs a network provider keeps, per its own privacy policy; Resend (Resend Inc., US) for access, purchase and requested-result emails and encrypted operator backups — never the uploaded statement or transaction rows — and Polar for payments. Verification records from paid conversions remain available at their random public URLs until deletion is requested. For access, correction or deletion requests, email hello@rowsure.com — a human answers.