How we protect your data
Remittance files contain sensitive financial information. Here's exactly what RemitParse does with your data, in plain language — and where we're still improving.
Uploaded remittance files are parsed in-process memory using pdfplumber and openpyxl. No write to disk occurs. The original bytes are discarded after the response is returned to the browser.
When you upload a remittance file, it's read and processed immediately in memory. The original file is never saved to a hard drive — it's gone as soon as your transactions appear on screen.
Extracted transaction data (invoice numbers, amounts, deduction codes) exists in the user's browser session only. It is not written to the database at any point during the coding workflow.
The transaction rows in your grid live only in your browser tab. We don't keep copies of your remittance transactions. Close the tab and they're gone.
Auto-Coding history stores only invoice alpha-key patterns, description tokens, coded types and contexts in a coding_history table scoped by company_id. Raw financial amounts are never stored.
If you use Auto-Coding, RemitParse remembers how you coded past deductions — the invoice pattern and the type you assigned. It does not store dollar amounts from your remittances.
Per-company configuration (customer mappings, deduction type mappings, Class/Location defaults) is persisted to PostgreSQL, with all queries scoped by company_id. Cross-tenant access is not possible at the query level.
Your settings are saved so you don't re-enter them each time. This data is strictly isolated to your account — no other company on RemitParse can access it.
Passwords are hashed using Werkzeug's generate_password_hash(), which uses pbkdf2:sha256 with a random per-user salt. Plaintext passwords are never stored, logged, or transmitted after the initial POST.
Your password is scrambled using a one-way algorithm before it's saved. Even we cannot read it. If our database were ever stolen, your password would not be exposed in readable form.
Session cookies are set with HttpOnly=True, SameSite=Lax, and Secure=True in production. The session payload is cryptographically signed using Flask's SECRET_KEY, which is stored as an environment variable and rotated periodically.
Your login session is stored in a secure cookie that JavaScript can't read, only works over HTTPS, and is signed so it can't be forged or tampered with.
Failed login attempts are counted per browser session. After 10 consecutive failures the endpoint returns HTTP 429 and locks the session. The counter clears on successful login.
After 10 wrong password attempts the login form locks. This prevents automated tools from guessing your password.
QBO OAuth 2.0 access and refresh tokens are encrypted at rest using Fernet symmetric encryption (AES-128-CBC + HMAC-SHA256) before being written to the database. The encryption key lives only in the server environment — never in code or the database.
Your QuickBooks credentials are encrypted before being saved. Even with direct database access, an attacker could not use your QBO tokens — they'd only see scrambled data.
RemitParse requests only the com.intuit.quickbooks.accounting OAuth scope. API access is limited to: CreditMemo (create), Customer (read), Item (read), Class (read), Department (read). No other QBO data is accessed or readable by the application.
When you connect QuickBooks, RemitParse asks for the minimum access needed — enough to create credit memos and look up your customers and product list only. It cannot see your bank accounts, payroll, invoices, payments, or financial reports.
Disconnecting QBO triggers an immediate DELETE on the qbo_connections row. Encrypted tokens are irrecoverably removed from the database at that instant — not queued or deferred.
Disconnecting QuickBooks permanently deletes your stored credentials from our system the moment you click disconnect — not on a schedule, immediately.
Application hosted on Render (SOC 2 Type II). TLS termination at Render's edge. HSTS header enforced in production (max-age=31536000; includeSubDomains). All communication between browser and server is encrypted.
RemitParse runs on Render, a SOC 2 certified cloud platform. All traffic is encrypted via HTTPS. Your browser is instructed to never attempt an unencrypted connection to remitparse.com.
Database hosted on Supabase (managed PostgreSQL). All connections use SSL. DATABASE_URL and all secrets are stored as environment variables — not in source code or version control.
The database runs on Supabase, a managed service with encryption at rest and in transit. Database credentials are not in the application code and have never been committed to version control.
All database queries use parameterized statements via psycopg2 — no string interpolation of user input into SQL. QBO API queries that require string interpolation (Intuit's query language) use explicit apostrophe escaping.
The application is built to prevent SQL injection — a common attack where malicious input is used to extract or corrupt a database. User input is never inserted directly into database queries.
Security questions?
Email us directly — we respond personally, usually same day.
info@remitparse.com →