> ## 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. # The submission packet > What result.submission_packet says about the submission as a whole. A packet is one submission. `result.submission_packet` answers what no single document can. | Field | What it says | | - | - | | `intake` | When and how it arrived (`received_at`, `source`), who sent it (`broker_email`: the form field, or the email's sender), the merchant it is filed under (`business_identity`: EIN, else your merchant id, else the application's EIN, else the statements, else the name), what each file was declared to be (`file_declarations`; recorded, never used in place of the classifier) and `request_content_sha256`. | | `documents` | Every typed document in packet order (`packet_index`), with its kind, type, pages, fingerprints, status and `excluded_reason`. | | `statement_exclusions` | Which documents the decision is not computed from, and why (below), plus `missing_months` only an excluded statement covered. Any exclusion sends the packet to review. | | `submission_intelligence` | `company_profile`: business, address and owner fields, each resolved (your request, else the application, else the statements' majority) with every source it was read from, never more than the SSN's last four digits. `transaction_coverage`: per account, month by month, covered, reconciled or missing. | | `mode_u` | Whether the decision statements are one account's continuous history (periods day after day, each closing balance the next opening), and if not, why. | | `cross_statement` | `balance_chain` (each seam between consecutive statements) and `missing_account_join` (accounts the merchant's own transfers mention that were not submitted). | | `packet_fraud` | Cross-document signals (edited resubmissions, balance-chain breaks, mismatched identities, overstated declared revenue): `{fraud_score, severity, reasons}`, [scored below](#fraud-score). `high` or `critical` sends the packet to review (`packet_cross_document_fraud`). Null when fewer than two documents can be compared. | | `review_reasons` | The packet's own reasons; they are also in the job's `review_reasons`. | ## Exclusion reasons | Code | The document is not used because | | - | - | | `duplicate_document` | The same statement appears again in the packet; one copy is used. | | `statement_excluded_parse_failed` | Its read failed: nothing usable could be read from it. | | `statement_excluded_unreconciled` | It was read, but its ledger did not verify. | | `activity_printout_unverified` | It is an online-banking activity printout without a complete running-balance chain, so there is nothing to verify it against. | | `unclassified_document` | It is neither a bank statement nor an application. | | `period_overlaps_another_statement` | Its period overlaps another statement of the same account. | | `account_holder_mismatch` | Its holder shares no word with the merchant's names (application business and owners, the declared name) nor with any other statement's holder. Otherwise a differing holder is only flagged. | ## Fraud score `packet_fraud.fraud_score` runs from 0 to 100: the weight of the strongest signal found, times 100. | Score | Set by | `severity` | Review | | - | - | - | - | | 0 | The documents were compared and agree | `clean` | no | | 60 | `declared_revenue_overstatement` alone | `medium` | no | | 85 | Any other signal | `high` | yes | | 95 | A `critical` reason (below) | `high` | yes | `severity` is banded from the score: 85 and above `high`, 60 and above `medium`, above 0 `low`, 0 `clean`. `high` or `critical` sends the packet to review; the packet itself is never rated `critical` (nor `unknown`) today, only a reason can be. Use `severity` to route, and `fraud_score` to rank or to feed your own scoring. Each of `reasons` is `{signal, severity, evidence, description}`: `evidence` states what was compared, with the values, and `description` what the signal means. | `signal` | Reason `severity` | The packet | | - | - | - | | `identity_mismatch` | high | The application's business or owner does not match the statements' account holders (or an ID). | | `account_number_mismatch` | high | A voided check's account is not the statement's. | | `declared_revenue_overstatement` | medium | The application states a monthly revenue far above what the statements show. | | `cross_statement_balance_chain_break` | high, or critical when both statements reconcile | A statement's closing balance is not the next one's opening balance. | | `duplicate_period_divergent_content` | high | One account and period sent twice, with different rows: an edited resubmission. | | `cross_statement_amount_divergence` | high | One transaction with two amounts across overlapping statements. | | `duplicate_account_under_distinct_labels` | high | One account sent twice under two labels. | ## Field keys Every key below is declared, with its meaning, in the API reference (`GET /v1/jobs/{job_id}`). A key a document does not carry is absent; none is ever renamed. * **`applications[].fields`**: `legal_business_name`, `dba`, `entity_type`, `ein`, `business_start_date`, `state_of_incorporation`, `industry`, `naics`, `business_phone`, `business_email`, `website`, `address_line_1`, `address_line_2`, `city`, `state`, `zip`, `requested_amount`, `use_of_funds`, `monthly_revenue`, `gross_annual_revenue`, `existing_advances_disclosed`, `broker_company_name`, `home_phone` (the principal's, where the form prints one), `signed` and `signed_date`. Values are as printed: dates `YYYY-MM-DD` where clear, amounts without commas, `signed` true or false (or the form's own text when only the text layer was read). * **`applications[].owners[]`**: `name`, `title`, `ownership_pct`, `email`, `mobile_phone`, `home_address`, `city`, `state`, `zip`, `date_of_birth`, `ssn_last4` and `credit_score`. By design an SSN is read as its last four digits only: no full SSN is ever in a result. (The documents you sent are kept as sent, sealed, until you erase the job.) * **`submission_intelligence.company_profile`**: every key is always present, each `{value, sources[]}`: `legal_business_name`, `doing_business_as`, `business_start_date`, `federal_tax_id`, `entity_type`, `state_of_incorporation`, `company_phone`, `company_website`, `company_email`, `industry_type`, `naics`, `annual_revenue`, `monthly_revenue`, `amount_requested`, `loan_purpose`, `address_line_1`, `address_line_2`, `city`, `state`, `zip_code`, `owner_name`, `ownership_percentage`, `mobile_phone`, `owner_email`, `ssn_last4`, `date_of_birth`, `credit_score`, `has_signed` and `signed_date`. The owner fields are the first owner's. * **`email`** (on the result and in the job's `intake`): `provider_message_id`, `mailbox_id`, `from`, `to`, `subject`, `received_at`, `attachment_count`, `processable_attachments`, `thread_id`, `supersedes` and `routing`. A later version may add a key; parse leniently and ignore what you do not know. ## Reading it ```bash theme={null} curl -sS "$API/v1/jobs/$JOB_ID" -H "X-API-Key: $KEY" | jq '{ documents: .result.submission_packet.document_count, excluded: [.result.submission_packet.statement_exclusions.excluded_documents[]? | {packet_index, reason_code}], fraud: .result.submission_packet.packet_fraud.severity, review: .result.review_reasons}' ``` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.