About Parseloom
Built by people who spent too long keying invoice data
Parseloom is an Austin-based team working on the document extraction problem that every ops and finance team hits at month-end.
The problem we're solving
Operations and finance teams in mid-size companies process hundreds of vendor invoices, shipping documents, and custom PDFs every month. Those documents don't share a format. Every vendor designs their own invoice. Every carrier uses a different bill of lading layout.
The default solution is manual keying: someone reads the PDF and types the values into the ERP. It's slow, error-prone, and gets worse at month-end when the volume spikes. Tools like basic OCR help with character recognition but don't understand the structure of the document - they can read the text, but they can't reliably tell you which text is the invoice total versus the subtotal versus a line-item price.
Parseloom's job is to make "understand this document's structure" a solved problem for your specific document types - so your team can stop keying and start doing work that's harder to automate.
The team
GSGrace Sullivan
CEO & Co-Founder
Previously ran AP operations at a regional distribution company for six years. Built internal Excel macros to speed up invoice keying before deciding the real fix needed to be software. Founded Parseloom in 2024 with Dev after a mutual frustration session at an ops conference in Dallas.
DMDev Martinez
CTO & Co-Founder
Eight years in document processing infrastructure, most recently at a logistics tech company where he built the internal pipeline for parsing carrier BOLs at scale. Focused on the extraction engine and ERP connector architecture at Parseloom.
LCLin Chen
Lead Engineer
Joined Parseloom from a fintech where she built ML pipelines for financial document classification. Leads template training, field-type detection, and the custom document builder at Parseloom. Based in Austin.
Origin
How we got here
In 2022, Grace was running AP at a mid-size Texas distributor processing about 400 vendor invoices a month. A small number of high-volume vendors had EDI connections that posted directly into SAP. Everyone else sent PDFs. Her team keyed those PDFs.
The math was obvious: at 6 minutes per invoice, that was 40 hours of keying a month, not counting review. The error rate during month-end crunch - when everyone was tired and rushing - was noticeably higher than mid-month. Three reconciliation issues in one quarter traced back to transposed invoice amounts.
She tried generic OCR tools. They could read the text. They could not reliably identify which text was the total, which was a line item, which was the header. Every vendor invoice is slightly different - column positions, font choices, whether line items are in a table or a list.
She eventually built a set of per-vendor Excel macros using data from a copy-paste step. It was fragile and took a full day to set up for each new vendor. It worked, but it wasn't a solution.
When she met Dev at an ops conference in Dallas in early 2024 and described the problem, he'd seen the same pattern from the technology side - document processing pipelines that worked great for one document type and fell apart the moment a vendor changed their layout. They started Parseloom six months later.
We're early and bootstrapped. The product works for our early-access teams' real documents. We're honest about where accuracy is strong and where it needs work. If you're hitting the same wall Grace was, we'd like to hear about your document types.
