> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parser-app.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Send a merchant's documents, get back verified bank-statement ledgers, the application, MCA positions and underwriting math.

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).

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    Submit your first packet and read its result in a few minutes.
  </Card>

  <Card title="How a packet is read" icon="magnifying-glass" href="/concepts/how-a-packet-is-read">
    From files to verified ledgers: what is checked, and when a person is asked to look.
  </Card>

  <Card title="Webhooks" icon="bolt" href="/guides/webhooks">
    Get told when a job finishes instead of polling.
  </Card>

  <Card title="Deals from email" icon="envelope" href="/guides/email-intake">
    Forward a deals inbox, or connect Gmail, Microsoft 365 or IMAP.
  </Card>
</CardGroup>

## What you can rely on

<AccordionGroup>
  <Accordion title="Numbers are never made up to fit">
    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.
  </Accordion>

  <Accordion title="Review is explicit">
    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.
  </Accordion>

  <Accordion title="Re-sent documents are not read again">
    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.
  </Accordion>

  <Accordion title="Your data stays yours">
    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.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.