Track underwriting conditions without spreadsheets
If you're tracking conditions in a spreadsheet while uploads are happening in email and text, you don't really have a tracker. You have a list of guesses about what's been sent.
Spreadsheets feel fine on day one. By day five of conditions, with partial uploads, two re-requests, and a borrower who keeps emailing PDFs instead of using the link, the spreadsheet is three tabs behind reality.
A good conditions tracker does two things: it shows what's still outstanding (and who's responsible), and it ties every condition to the exact document that satisfies it. That second part is what spreadsheets can't do.
What a tracker actually needs to show
Most teams overcomplicate this. The minimum fields that prevent conditions from slipping through:
- Condition description (copy and paste the exact UW language, don't paraphrase)
- Category (income, assets, ID, property, credit, other)
- Who's responsible (borrower, LO, processor, third party)
- Requested date
- Status (Requested / Received / Needs re-upload / Submitted to UW / Satisfied)
- Notes (what exactly is missing or wrong)
That's it for most files. If you want more, add:
- Due date
- The condition number from the UW findings (makes re-submissions cleaner)
- The filename or link where the satisfying document lives
The 5-step workflow that keeps the tracker honest
Step 1: Paste the UW language directly.
Don't translate conditions into something friendlier at this stage. Keep the original wording in your tracker so you can verify the right document was collected. You can translate it for the borrower in the request, but keep the source language for your own reference.
Step 2: Normalize your statuses.
Pick 5-7 statuses and stick to them. If one processor uses "Pending" and another uses "Awaiting Receipt" and another uses "Got It," the tracker lies. Agreed statuses everyone uses the same way:
- Requested
- Received (but not yet reviewed)
- Needs re-upload
- Submitted to underwriting
- Satisfied / cleared
Step 3: Request one condition at a time.
"Please send updated bank statements, a new paystub, and a signed P&L" is three separate requests in one message. The borrower answers one of them and thinks they're done. Request each condition separately so you can track each one independently.
Step 4: Mark Received only when you've actually looked at it.
If you mark Received the moment a file comes in, then find out two days later it's missing pages, your tracker has been wrong for two days. Do a quick scan first: are all pages there, is the date range right, is it legible? Then mark Received.
Step 5: When a document gets rejected, log why.
This is the one most people skip. "Needs re-upload" without a reason means the borrower re-uploads the same incomplete file. The reason goes on the item: "missing pages 4-6," "wrong date range, need January not December," "signature page not included."
Copy/paste request scripts
For borrower re-upload requests, specific beats vague every time:
"Thanks for uploading. Underwriting reviewed this and we need a complete version. Please re-upload all pages of your [BankName] statement for [Month] (including blank pages). Download the full PDF from your bank's website and use this link to re-upload it."
For internal updates to the LO:
"Conditions update: [#] open. Top blocker is [Condition X]. Borrower was re-requested on [date] for [reason]. Target resubmission: [date]."
Why "Received" and "Satisfied" are different statuses
Receiving a document and satisfying a condition are two separate events. A document can be received and still fail review. A condition can have multiple documents submitted before one finally meets requirements.
Keeping them separate lets you submit a partial re-submission when some conditions are satisfied and others aren't, rather than waiting until everything is perfect before sending anything to underwriting.
Ready to get started?
Try using BorrowerDocs to send a borrower portal, collect secure uploads, and track document status in one place.
Start for Free