Reporting · LendEasy Docs

Discover the operational report catalog through the API, understand where execution happens, and reconcile every report back to source facts.

Reporting is a product contract, not arbitrary database access. The public API exposes the report-definition catalog—each report’s name, category, and parameters—while report execution and downloads are operator-side. Integrations discover what exists through the API; they do not run reports through it.

The report-definition catalog

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—so downstream consumers can validate what a delivered extract claims to represent.

The operational report set

Execution happens in the operator console against these definitions. 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	Sales provenance, 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

There is no public run, schedule, or download route for report execution. Operators run a definition with its parameters, and the resulting extract is delivered through the operator console under its access controls. 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; operational UIs should use the corresponding current read model—the loan summary, not last night’s portfolio row. 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.

Permissions and minimization

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

Reconciliation, not reconciliation theater

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; they are not forced into “failed” to make a chart balance.

Credit furnishing

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.