Skip to main content
Parser reads a merchant cash advance submission: the application and the bank statements an ISO, broker or merchant sends you, uploaded through the API or arriving by email. It returns structured, checked data:
  • Verified ledgers: every transaction of every statement, signed and dated, reconciled to the cent against the bank’s own printed totals and running balances.
  • The application: business, owners, addresses and the funding request, each field with where it was read.
  • Months and accounts: true revenue, NSF and overdraft counts and EBITDA per calendar month and account.
  • Positions: the advances and loans the merchant is repaying now, with the funder, payment and cadence.
  • Underwriting: average monthly revenue, existing MCA burden, current withhold, stacking and capacity.
  • The packet: which documents the decision rests on, which were excluded and why, and the checks only the whole submission can answer (balance chains across statements, undisclosed accounts, cross-document fraud).

Quickstart

Submit your first packet and read its result in a few minutes.

How a packet is read

From files to verified ledgers: what is checked, and when a person is asked to look.

Webhooks

Get told when a job finishes instead of polling.

Deals from email

Forward a deals inbox, or connect Gmail, Microsoft 365 or IMAP.

​
What you can rely on

A ledger is verified only when it reconciles (opening + credits - debits = closing), matches the bank’s printed totals and keeps every running balance. A printed amount is never rewritten to make the totals close. A statement that does not verify is marked for review, and its rows are left out of the metrics.
Every job ends completed, review_required or failed. A job sent to review is still usable, and its review_reasons name exactly what a person should check.
The same statement sent again, re-saved or merged into another ISO’s PDF is recognised by its content and its earlier read reused, so the numbers never differ between submissions and it costs nothing.
Every record belongs to one tenant, and the database itself refuses one tenant’s rows to another. Documents are encrypted at rest with your tenant’s own key.