What is a borrower portal in commercial lending?

A borrower portal is a lender-provided surface where a commercial borrower can see what deliverables are outstanding, submit them, and track what has been received. Better implementations also let the borrower connect an accounting system so financial data flows directly rather than being exported to PDF and emailed.

Can borrower financial statements be collected automatically?

The request, reminder, receipt, and status tracking can be fully automated. Whether the underlying data arrives automatically depends on the borrower. If they connect an accounting system such as QuickBooks, Xero, or NetSuite, general ledger data can flow directly. If they submit documents, the collection workflow is automated but a document still has to be produced and read.

Do borrowers object to connecting their accounting system?

Some do, and the objection is reasonable. The considerations that matter are that access is read-only, that it is scoped to the financial data needed rather than the whole system, and that the borrower can revoke it at any time. Borrowers who decline should stay on document submission; treating the connection as mandatory turns a convenience into a relationship problem.

Does connected accounting data replace audited financial statements?

No. General ledger data reflects what the borrower has recorded, before year-end adjustments, accruals, and auditor changes. Where a credit agreement requires audited or reviewed statements, connected data does not satisfy that requirement. It is valuable as an interim signal and as a way to remove the round trip on internally prepared reporting, not as a substitute for assurance.

Solutions

Borrower reporting automation, or how to stop chasing PDFs.

Collection is where most of the elapsed time in covenant monitoring actually goes. It is also the least judgment-dependent part of the process, which makes it the highest-return thing to automate first.

What is borrower reporting automation?

Borrower reporting automation

Borrower reporting automation generates a dated deliverable calendar from each credit agreement's reporting covenants, then handles requesting, reminding, receiving, and tracking those deliverables without a person maintaining the list by hand.

The case for starting here is straightforward. Collection consumes the most time of any stage in covenant monitoring, requires the least credit judgment, and blocks everything downstream. A covenant cannot be tested for a period whose financials never arrived, so every collection failure becomes a testing failure.

The background on what agreements actually require and why deliverables run late is on borrower reporting requirements.

The workflow

From reporting covenant to received document

1
Reporting covenants become dated obligations
The delivery requirements extracted from the credit agreement generate a per-borrower calendar: what is owed, in what form, and by when, across every deliverable rather than just the financial statements.
2
Requests go out ahead of the deadline
Notice before the due date changes behaviour far more than chasing after it. Requests state exactly what is needed and for which period.
3
The borrower sees a single outstanding list
One place showing what is due, what has been received, and what is late, rather than an email chain the borrower has to reconstruct.
4
Submission, or direct connection
The borrower uploads documents, or connects an accounting system so financial data flows without an export step. Bank balance verification can come from the borrower's deposit accounts where relationship covenants require it.
5
Receipt recorded with its arrival date
Not just marked complete. Recording when each deliverable actually arrived is what turns reporting into a trend signal rather than a binary flag.
6
Reminders escalate on their own
Missed deadlines escalate to the relationship manager without anyone having to notice, and persistent delinquency surfaces as a reporting exception.
7
Data flows into testing
Received financials feed covenant calculations for the period, so testing happens as data arrives rather than in a quarter-end batch.

The collection loop, generated from the agreement rather than maintained by hand.

Covering every deliverable, not just financials

Most manual processes track quarterly financials reasonably well and everything else poorly, because the other deliverables run on calendars that do not align with the reporting cycle.

Financial statements

Interim and annual, with the basis of preparation tracked, internally prepared, reviewed, or audited, because some covenants are tested only against audited figures.

Compliance certificates

Much of what a certificate asks for is already known to the lender or derivable from the financials just submitted, so pre-filling removes most of the borrower's effort.

Tax returns

Business and, for closely held borrowers, guarantor personal returns. A chronic source of delinquency because filing extensions push timing outside the borrower's control.

Borrowing base certificates

Monthly or more frequent in asset-based structures, with accounts receivable ageing and inventory detail attached. The highest-frequency deliverable in most portfolios.

Insurance documentation

Renewal-driven rather than fiscal-period driven, which is exactly why it is the most-missed item in manual processes. The calendar comes from policy dates.

Budgets, rent rolls, and other items

Projections, property operating statements, covenant-specific schedules. Low volume individually, and collectively the long tail where manual tracking fails.

Connected accounting data, and its limits

The most significant change available in this workflow is removing the document round trip entirely. Rather than a borrower exporting a balance sheet to PDF and emailing it, the borrower authorises a read-only connection and the underlying data flows.

CovenantFlow reaches borrower accounting systems through Codat, which covers QuickBooks, Xero, NetSuite, Sage, and Dynamics, with a direct QuickBooks Online integration as a backstop, and can verify deposit balances through Plaid where relationship or liquidity covenants require them.

What this genuinely improves

Interim reporting arrives without the borrower doing anything each period.
Data is structured on arrival, so no spreading step is needed for the connected figures.
Period-over-period comparison is consistent, because the extraction is identical each time.
Compliance certificates can be pre-filled from data the lender already has.

What it does not do

It does not replace audited statements. General ledger data is pre-adjustment and pre-audit. Where the agreement requires audited or reviewed financials, a connection does not satisfy that.
It does not resolve definitional questions. Whether a particular expense qualifies as a permitted add-back is still a judgment, and the general ledger will not answer it.
It is not universal. Borrowers on older or bespoke systems, and those who simply decline, stay on document submission. That has to be a supported path, not an exception.
It requires borrower consent, properly framed. Read-only, scoped, and revocable at any time. Treating the connection as mandatory converts a convenience into a relationship problem.

More on the accounting side in QuickBooks and NetSuite.

Designing for the borrower, not just the bank

Worth stating explicitly, because collection tooling is usually designed entirely around the lender's convenience and then underperforms for exactly that reason.

The borrower is a commercial customer, frequently with a small finance team, who did not choose this workflow. If the portal is confusing, requires a new login for every request, or does not clearly state what is outstanding, they will revert to email and the automation will have moved the problem rather than solved it.

The properties that matter to the borrower: one place that shows what is owed and what has been received, requests that specify the period and the form, the ability to connect an accounting system once rather than submit repeatedly, and visibility into what the lender is actually watching. Reporting compliance improves when the borrower has less work to do, which is a more reliable mechanism than escalation.

FAQ

Frequently asked questions

What is borrower reporting automation?: Borrower reporting automation generates a dated deliverable calendar from each credit agreement's reporting covenants, then handles the requesting, reminding, receiving, and status tracking of those deliverables without a person maintaining the list by hand. It covers financial statements, compliance certificates, tax returns, borrowing base certificates, insurance evidence, and any other required borrower submission.
What is a borrower portal in commercial lending?: A borrower portal is a lender-provided surface where a commercial borrower can see what deliverables are outstanding, submit them, and track what has been received. Better implementations also let the borrower connect an accounting system so financial data flows directly rather than being exported to PDF and emailed.
Can borrower financial statements be collected automatically?: The request, reminder, receipt, and status tracking can be fully automated. Whether the underlying data arrives automatically depends on the borrower. If they connect an accounting system such as QuickBooks, Xero, or NetSuite, general ledger data can flow directly. If they submit documents, the collection workflow is automated but a document still has to be produced and read.
Do borrowers object to connecting their accounting system?: Some do, and the objection is reasonable. The considerations that matter are that access is read-only, that it is scoped to the financial data needed rather than the whole system, and that the borrower can revoke it at any time. Borrowers who decline should stay on document submission; treating the connection as mandatory turns a convenience into a relationship problem.
Does connected accounting data replace audited financial statements?: No. General ledger data reflects what the borrower has recorded, before year-end adjustments, accruals, and auditor changes. Where a credit agreement requires audited or reviewed statements, connected data does not satisfy that requirement. It is valuable as an interim signal and as a way to remove the round trip on internally prepared reporting, not as a substitute for assurance.

Keep going

See the borrower portal and collection workflow

Deliverable calendars generated from the credit agreement, automated requests, and accounting connections that remove the document round trip.