Ratesheet automation software, end-to-end.

Why this matters in dollars

Most originators run a daily ritual: an ops person logs into eight to twenty wholesale-lender portals, downloads the morning ratesheet, opens each in Excel, and either manually re-types the relevant rows into the LOS or pastes them into a master spreadsheet. The same person also fields the email distributions that arrive across the day. Every error is a pricing error; the audit trail lives in the inbox.

At a typical correspondent originating 3,000 loans per year with eight active investors, that's roughly 8 investors × 0.5 hours/day × 250 business days × $75/hr loaded rate ≈ $75,000/year of pure ratesheet wrangling — before counting the cost of mistakes that propagate to live pricing. Automation removes 80–90% of that cost on day one and improves quality monotonically as the template engine learns.

Anatomy of an automation pipeline

1. Source. Email IMAP polling, headless-browser portal scrape, web/API scrape, or file upload. Every source produces a raw blob and metadata.
2. Fingerprint. The blob is hashed and de-duplicated. The same ratesheet arriving twice (email + portal) is processed once.
3. Convert. Excel, PDF, or image-only PDF is converted into a canonical {sheets: [{rows: [...]}]} JSON shape. POI for Excel, PDFBox for PDFs, Tess4J for OCR.
4. Extract. Table detection isolates rate grids; segmentation classifies each grid (base-rate, adjustment, eligibility, buydown). The output is structured rate rows with row-level metadata.
5. Map. A three-tier resolver matches columns to canonical fields: stored template (fast, exact), AI-assisted (handles novel formats), regex fallback (deterministic, predictable). New templates are saved automatically once an operator confirms.
6. Version. The new ratesheet enters DRAFT. After automated quality checks pass, an operator activates it (DRAFT → ACTIVE). The previous version moves to SUPERSEDED but stays queryable for historical replay.
7. Distribute. Pricing engines that subscribe to the ratesheet stream are notified; cache invalidation is event-driven, not TTL-based.

What to evaluate

• Source coverage. Does the system handle the actual channels your investors use today? Run the trial by pointing it at three of your messiest investors, not three of your easiest.
• Template behavior on novel formats. Drop in a ratesheet from an investor the system has never seen. How long does it take an operator to onboard? Does the system get faster on the second sheet?
• Versioning + rollback. Activate a ratesheet, then roll it back. Verify the audit trail shows both transitions and the previous version is queryable.
• Quality gates. What automated checks run before a ratesheet can be activated? Cross-investor consistency? Cell range sanity? Schema-mismatch detection?
• Operator UX. The operator is going to live in this tool. The QC inbox, mapping editor, and ratesheet diff view are the three surfaces that matter most.

Common evaluation mistakes

• Evaluating only against your easiest investors. Onboard the messiest one in the demo.
• Trusting demo accuracy on perfectly-formatted PDFs. Insist on a production-shaped sample with the realistic mix of clean PDFs, image PDFs, and Excel quirks.
• Ignoring the QC review queue. The bottleneck in production is human review of low-confidence extractions; the queue UX matters more than the model accuracy headline.
• Skipping the versioning test. A surprising number of vendors don't actually preserve immutable historical ratesheets — they overwrite the ACTIVE row in place. Verify before you sign.