Every closing is a small pile of documents that show up in a different order, from a different source, with a useless name. The listing agreement comes in as a signed scan. The inspection report arrives as an email attachment. The settlement statement is downloaded as Document(3).pdf. On a one-person operation this is annoying. On a team, where four people touch the same deal, it turns into chaos: nobody can find the counteroffer because the agent who saved it named it however felt natural that day.
How to keep real estate transaction files organized across a team
To keep real estate transaction files organized across a team, agree on one folder structure (Property > stage), one naming pattern, and one per-transaction document checklist, then make filing automatic so no single agent or coordinator has to remember the convention. Sortio reads each document's content, names it to the agreed pattern, and routes it to the correct property and stage folder, so everyone on the team produces an identical, predictable layout without manual sorting. Consistency stops depending on discipline and starts being the default.
The rest of this post is the concrete version: the folder tree and naming pattern you can copy, the checklist of what belongs in a complete file, why content-based sorting beats both hand-filing and rigid rules for this job, and a working Sortio prompt the whole team can share. It positions Sortio as the layer that gets your raw local files named and filed before they ever go into your transaction management platform, not as a replacement for one.
The short version
Standardize on a per-property tree split by stage (Listing, Offers, Under-Contract, Closing) with a fixed naming pattern, then let Sortio enforce it. Sortio reads each file's content, applies the pattern, and routes it to the right property and stage folder, so every agent and coordinator files the same way. Run it once on a backlog or as a watch folder on intake. What lands in your transaction platform is already clean and consistently labeled.
The folder structure: property, then stage
The structure that survives a busy pipeline is per-property, split by transaction stage. The property is the top level so each deal is self-contained, and the four stages map to how a deal actually moves: Listing, Offers, Under-Contract, Closing. Numeric prefixes on the stage folders force them to sort in deal order instead of alphabetically.
~/Transactions/
123_Main_St_Anytown/
01_Listing/
2026-04-02_123-Main-St_Listing-Agreement.pdf
2026-04-02_123-Main-St_Sellers-Disclosure.pdf
02_Offers/
2026-04-18_123-Main-St_Purchase-Agreement_Buyer-Nguyen.pdf
2026-04-19_123-Main-St_Counteroffer_v1.pdf
2026-04-18_123-Main-St_Proof-of-Funds.pdf
03_Under-Contract/
2026-04-25_123-Main-St_Inspection-Report.pdf
2026-04-29_123-Main-St_Repair-Request.pdf
2026-05-04_123-Main-St_Appraisal.pdf
2026-05-06_123-Main-St_Title-Commitment.pdf
04_Closing/
2026-05-20_123-Main-St_Closing-Disclosure.pdf
2026-05-22_123-Main-St_Settlement-Statement.pdf
2026-05-22_123-Main-St_Recorded-Deed.pdfThe naming pattern under every stage is the same, which is what makes the whole thing scannable across a team:
{YYYY-MM-DD}_{Property-Short}_{DocType}[_{Detail}].pdfISO date first so files sort chronologically inside each stage. A short property slug second so a file is identifiable even if it gets copied out of its folder. The document type next (the same controlled vocabulary every time: Listing-Agreement, Purchase-Agreement, Inspection-Report, Closing-Disclosure) so a human or a search can find a document type across every deal. An optional detail at the end for versions or counterparties (Counteroffer_v1, Buyer-Nguyen). Because the document type comes from a fixed list rather than whatever each agent types, you can answer "do we have an appraisal on every active deal" by glob, not by opening folders.
The per-transaction document checklist
A complete file is the same set of documents every time, grouped by the stage they belong to. The exact list varies by state and brokerage, but the shape holds. The value of writing it down is that anyone can open a property folder and instantly see what is filed and what is still missing.
01_Listing [ ] Listing agreement (signed) [ ] Seller's disclosure [ ] Lead-based paint / state disclosures [ ] Comparative market analysis 02_Offers [ ] Purchase agreement [ ] Addenda and counteroffers [ ] Buyer pre-approval or proof of funds [ ] Earnest money receipt 03_Under-Contract [ ] Inspection report [ ] Repair request / response [ ] Appraisal [ ] Title commitment [ ] Loan commitment 04_Closing [ ] Closing disclosure (signed) [ ] Settlement statement [ ] Recorded deed [ ] Wiring / disbursement confirmation
On a team, this checklist is the contract between the agent and the transaction coordinator. The coordinator does not have to chase an agent for "the file" in the abstract. They can say "Under-Contract is missing the appraisal" because the folder and the checklist make the gap obvious.
Manual vs rule-based vs AI-by-content
There are three ways to get a document into the right folder with the right name, and they fail in different places.
By hand is accurate and needs no setup, but it does not scale and it is the first thing that gets dropped when a deal is moving fast. It also produces inconsistent results across a team, because each person's idea of a good filename is slightly different. This is the default state of most brokerages and it is exactly the problem.
Rule-based automation (a macOS Folder Action or Automator workflow, a Hazel rule on Mac, File Juggler on Windows) is fast and free and runs unattended. The catch is that a rule acts on the filename, the extension, or at best a regex against the text layer. It cannot tell a purchase agreement from an inspection report when both arrive as scan_0421.pdf, and the moment a form template changes, a regex stops matching. Rules are great for stable, predictable inputs and brittle for the messy reality of transaction documents.
AI-by-content is what Sortio does. It opens each file, reads the actual content with an LLM, and decides which property and stage it belongs to and what to name it, regardless of the incoming filename. It is robust to scans and OCR noise that break regex, and it understands document structure (it knows a settlement statement is a settlement statement). The trade-off is that AI sorts consume credits and take longer than a regex. For a stable, high-volume pattern you can promote a decision to the AI Rule Builder, which generates a deterministic rule that runs without consuming AI credits. For the full decision framework, see AI Sort vs Rule Builder.
A working Sortio prompt for transaction documents
This is the shared prompt the whole team uses. Point it at the folder where documents land (Downloads, or a dedicated intake folder) and run Preview before applying. Replace the property list with your active deals, or let the model infer the property from the address printed on each document.
Read each file and identify (1) which property it belongs
to from the address inside the document, and (2) which
transaction stage it is: Listing, Offers, Under-Contract,
or Closing.
File it under:
~/Transactions/{Property-Short}/{01_Listing |
02_Offers | 03_Under-Contract | 04_Closing}/
Stage mapping:
- Listing agreement, seller's disclosure, CMA -> Listing
- Purchase agreement, addenda, counteroffers, proof of
funds, earnest money receipt -> Offers
- Inspection report, repair request, appraisal, title
commitment, loan commitment -> Under-Contract
- Closing disclosure, settlement statement, recorded
deed, wiring confirmation -> Closing
Rename every file to:
{YYYY-MM-DD}_{Property-Short}_{DocType}[_{Detail}].pdf
Use the document's own date (signing or report date).
Property-Short is the street number and name, hyphenated
(123-Main-St). DocType comes from this fixed list:
Listing-Agreement, Sellers-Disclosure, CMA,
Purchase-Agreement, Counteroffer, Proof-of-Funds,
Inspection-Report, Repair-Request, Appraisal,
Title-Commitment, Closing-Disclosure, Settlement-Statement,
Recorded-Deed. Add _Detail only for versions
(Counteroffer_v1) or parties (Buyer-Nguyen).
If you cannot identify the property or stage with
confidence, leave the file in ~/Transactions/_Inbox/
untouched.Click Preview. Sortio shows the proposed name, target property, and stage for every file, plus the values it read out of each document. A coordinator can review the whole batch at a glance and override any single decision before applying. If the model gets a property or document type wrong on a file, fix that one and Sortio remembers the manual correction. Nothing is destructive, and the Sortio backup folder keeps the originals of anything renamed for 30 days.
Making the whole team file the same way
The reason team filing drifts is that it depends on every person remembering a convention while juggling live deals. The fix is to take the remembering out of the loop. On Sortio Pro ($14.99/month or $99/year) you can turn the shared prompt into a watch folder so intake is handled automatically:
- Designate one intake folder per person (or a shared one) where transaction documents are saved or scanned.
- In Sortio, open Watch Folders, add the intake folder, and paste the shared prompt above so every machine runs the identical logic.
- Leave the watch in Preview mode for the first week. Sortio queues the proposed moves and notifies the user instead of applying them, so a coordinator can confirm the AI is classifying correctly before trusting it.
- After a week of clean previews, switch to Apply. From then on, every document that lands is named and filed within seconds, the same way for every person.
For brokerages, Sortio Teams ($29/seat/month) adds shared rules and an admin console so the naming pattern and stage mapping are managed centrally rather than copied prompt by prompt. A new transaction coordinator inherits the convention on day one and produces the same clean layout as someone who has been on the team for years. This is the same principle behind a durable naming standard in general, covered in how to enforce a file naming convention.
Where Sortio fits with your transaction platform
Most teams already run a transaction management platform for compliance, e-signature, and broker review. Sortio does not replace that. It is the step before it. Raw files arrive on a laptop as scans, downloads, and email attachments with names like scan_0421.pdf, and historically a person has to open each one, figure out what it is, rename it, and put it in the right place before it gets uploaded or synced. Sortio automates that messy local step: it reads the content, applies your naming pattern, and routes the file to the correct property and stage folder, so what flows into your platform is already clean and consistently labeled instead of a pile of generic scans.
That clean, consistently named folder is also what makes a file defensible later. If a deal is ever questioned, the difference between a folder of scan_0421.pdf files and a stage-ordered, checklist-complete archive is the difference between an afternoon of reconstruction and a two-minute pull. For the audit-readiness side of this, see how to make client files audit-ready.
Privacy and local processing
Transaction documents are sensitive: they carry names, addresses, financials, and signatures. Sortio supports local-only inference through Ollama, so the LLM runs on the machine (Llama 3, Mistral) and no document content leaves it. The managed AI option (Sortio-hosted or BYOK) is faster and more accurate and can re-OCR scans during the sort run. Either way, sorting is non-destructive, runs behind a preview, and keeps 30-day backups, so nothing changes on disk until a person confirms it.
FAQ
How do you organize real estate transaction files across a team?
Pick one folder structure (Property > stage: Listing, Offers, Under-Contract, Closing), one naming pattern, and one per-transaction document checklist, then make filing automatic so no individual agent or coordinator has to remember the convention. Sortio reads each document's content, names it to the agreed pattern, and routes it to the correct property and stage folder, so every person on the team produces an identical, predictable file layout without manual sorting.
What folder structure works best for a real estate transaction?
A per-property folder split by transaction stage holds up better than one big folder per deal. Top level is the property (123_Main_St_Anytown), then four stage subfolders: 01_Listing, 02_Offers, 03_Under-Contract, 04_Closing. The numeric prefixes force the stages to sort in deal order in Finder or Explorer. Each stage holds the documents that belong to it (listing agreement and disclosures in Listing, purchase agreement and counteroffers in Offers, inspection and appraisal in Under-Contract, settlement statement and signed deed in Closing).
What documents belong in a complete transaction file?
A typical residential file has: the listing agreement and seller disclosures (Listing), the purchase agreement, addenda, counteroffers, and proof of funds or pre-approval (Offers), the inspection report, repair requests, appraisal, and title commitment (Under-Contract), and the settlement statement, signed closing disclosure, and recorded deed (Closing). The exact set varies by state and brokerage. The point of a per-transaction checklist is that anyone can open the folder and immediately see what is filed and what is still missing.
How do I get every agent on the team to file documents the same way?
Stop relying on people to remember the convention and let the tool enforce it. Sortio reads the content of each document, figures out which property and stage it belongs to, names it to the shared pattern, and files it, so the result is identical no matter who dropped the file in. As a watch folder it does this automatically on every new arrival, which means a new coordinator produces the same clean layout on day one as someone who has been on the team for years.
Does Sortio replace Dotloop, SkySlope, or my brokerage transaction platform?
No. Sortio is the layer that gets your raw local files named and filed correctly before they go into a transaction management platform. Scans, email attachments, and downloads usually land in Downloads with names like scan_0421.pdf, and someone has to identify and rename each one before uploading. Sortio reads the content, applies your naming pattern, and routes the file to the right property and stage folder, so what you upload (or sync) into your platform is already clean and consistently labeled.
Can Sortio handle scanned closing documents with no useful filename?
Yes. A scanned settlement statement or signed disclosure has no useful name and no metadata to sort on. Sortio opens the scan, runs OCR when the file has no text layer (the managed AI tier can re-OCR scans during the sort run), reads the result, and files the document by what it actually is, a closing disclosure or a recorded deed, rather than by scan_0421.pdf. Run Preview to confirm the proposed names and destinations before anything moves.
How is content-based AI sorting different from a rule or doing it by hand?
By hand is accurate but does not scale and is the first thing that gets skipped when a deal is busy. A rule engine like a Finder Folder Action or a Hazel rule is fast and free but acts on the filename or extension, so it cannot tell a purchase agreement from an inspection report when both are named scan_0421.pdf. Sortio reads the actual content with an LLM, so it routes by what the document is. For high-volume, stable patterns you can promote a decision to the AI Rule Builder, which runs deterministically without consuming AI credits.