Renewals are re-originations today
A renewal is the loan an ag lender most wants to make: a known operation, a known loan, a relationship that has already been through a few seasons. And yet it moves through the same manual path as a brand-new application, re-keyed by staff, one record at a time. One at a time, a renewal is a servicing action you can run in the borrower portal; a book of them arriving at once is a different problem.
- The wave is the problem. Operating-loan renewals arrive all at once, ahead of planting, against a funding deadline the season sets. Staffing for the peak means overstaffing for the year.
- Volume grows faster than teams do. When staff cannot keep up, loans get extended rather than repriced, and the lender absorbs the cost.
- Hand-built lists carry errors. Eligibility spreadsheets assembled by hand mis-renew borrowers, miscount renewal terms, and route work through parties who only exist in the flow because a legacy system required it.
Same pipeline as every other loan
Batch renewals are not a side system. Your file is mapped to your template and every row is checked before anything is created; each valid row then becomes an ordinary loan request in the Origination pipeline you already run, tiered and decisioned against the renewal eligibility rules you authored for that program. Queues, underwriting, letters and booking behave exactly as your team expects, and approved renewals book against the borrower’s existing core banking record.
Nothing exists in the platform until you say process. Failed rows come back with the reason, the field and the fix; correct the file and re-upload, and a re-upload does not create duplicates.
What it does not do
The guardrails are intentional: automation where it helps, judgment where it matters.
- It does not auto-decline. The engine has two outcomes, auto-approve or refer to a human underwriter. Decline stays a human decision, on your existing adverse-action letters.
- It does not decide who belongs on your renewal book. Sweet validates rows — identity, duplicates, program access, limits — but the list is yours.
- It does not lose a row quietly. Frozen credit reports and bureau errors surface as named exceptions your team can work — they are not scored, and they are not approved.
- It does not leave you holding a bad batch. Every request a batch created is reachable, and reversible, from the batch itself.
- It does not touch compliance. Letters ride the same generation your team already runs in production, and the notification switch cannot suppress a regulatory letter.
Renewals first, not renewals only
Underneath the feature is batch request creation, and everything lender-specific is configuration rather than code: the file, the template, the eligibility rules authored per program, and borrower involvement as a per-batch option. Because batch-created requests are ordinary requests, the borrower steps — invite, confirm, e-sign — switch on per batch, on the same request Document Collection and the rest of the pipeline already know how to run. The same machinery is what extends to batch covenant requests, and to servicing-triggered renewals with no file at all.
Learn more about the platform end to end, or read the Origination FAQ.
