Reporting · LendEasy Docs

The report catalog is discoverable through the API while execution stays operator-side, so any extract can be traced back to the definition and parameters that produced it.

A report is worth only as much as your ability to say what produced it. A figure nobody can trace back still ends up in a board pack, and by then it is being defended rather than checked. So the catalog of report definitions—each report’s name, category, and parameters—is public API, and every delivered extract can be matched back against the definition and parameters it claims to represent. The servicing workspace adds a curated investor reporting pack on the same authoritative facts.

discovery

The API says what exists

Every definition, with its category and its parameters
Plus one download: reconciliation exceptions as a CSV

execution

The console runs it

No public run, schedule or download route for a report
Operators supply the parameters and receive the extract

Neither side reaches the database directly. An integration that could run a report could run one whose parameters nobody recorded, so discovery is the half that automates safely.

A definition names its own parameters

curl "$BASE/v1/reports" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender"

[
  {
    "id": 81,
    "reportName": "Credit balance accounts",
    "reportType": "Table",
    "reportCategory": "Loan",
    "useReport": true,
    "reportParameters": [{ "id": 1, "parameterName": "asOfDate" }]
  }
]

GET /v1/reports/{id} returns one definition with its parameters. Both reads require the READ_REPORT permission. A definition tells you exactly which parameters an operator supplies when running the report—asOfDate above.

Each report declares its own grain

Grain is the first thing to read on any definition, because it decides what a row can honestly be counted as. The set includes, among others:

Report	Grain	Primary controls
Portfolio summary	One row per obligation	As-of date, product, currency.
Delinquency roll	One row per loan and bucket date	Effective payment facts and bucket policy.
Payment and funding reconciliation	One row per intent	Provider, rail, ledger, and difference state.
Statement inventory	One row per statement version	Cutoff, due date, supersession.
Merchant remittance	One row per sales-report period	Where the sales figures came from, rate, settlement, posted reduction.
Credit balance accounts	One row per qualifying account	Balance components, age, restriction, refund status.

The credit-balance accounts report is the operational watchlist for accounts owing money back to borrowers; its rows feed the governed credit-balance-refund workflow rather than triggering refunds themselves.

Execution and download are operator-side

When an integration needs report output, treat the delivered file as an operator-produced artifact: verify which definition and parameters produced it before consuming it.

The one API-downloadable export is reconciliation: GET /v1/recon-exceptions/export streams unresolved reconciliation exceptions as a CSV attachment and marks the exported open rows as exported, so repeated pulls do not double-count the same backlog.

Freshness is part of the result

Each report derives from declared sources and an as-of parameter. A portfolio extract can be internally consistent and still be too stale for a live collection decision, so operational screens read the current model—the loan summary—rather than last night’s portfolio row. A collector working from the overnight extract calls a borrower who paid at breakfast, and the borrower remembers that call for a long time. When evaluating a delivered report, distinguish:

the requested as-of date;
the time the report was actually produced; and
known incomplete or degraded source domains at production time.

Output is filtered before it exists

The catalog read is permission-gated like every other resource, and report output is filtered for the operator who runs it before any artifact exists. Filtering the file afterwards would be too late: an extract is the most copied thing a lender produces, and it lives on in mailboxes and shared drives long after the person who ran it has changed roles. Extracts never include raw payment credentials or vault-tokenized identifier values, and the reconciliation CSV export requires the reconciliation read permission—downloading it is itself an audited act.

A report shows its own arithmetic

Useful reports expose their arithmetic. For a payment cohort:

opening submitted intents
+ new intents
− cancelled intents
− posted intents
− failed intents
= closing in-flight intents

Counts and amounts must reconcile independently. Unknown states remain visible as exceptions rather than being folded into “failed” to make a chart balance—an unknown rounded into a known is an error that has been hidden from the only person who could have caught it.

Furnishing is a data product, not a toggle

Where furnishing is configured, its output is a controlled downstream data product from authoritative loan facts and policy—not a general report toggle. Corrections, disputes, effective dates, and file acceptance require their own workflow and evidence. LendEasy does not claim that producing a file by itself satisfies a lender’s furnishing obligations.

Reports never mutate loans or resolve exceptions. A report can identify a discrepancy; repair runs through the governed payment, funding, action, or reconciliation workflow that owns the underlying fact.