The Texas Data Privacy and Security Act took effect July 1, 2024. Most privacy-law coverage focuses on consumer-facing applications — websites, apps, marketing databases. What gets less attention is the quiet implication for enterprise back-office workflows that process documents containing personal data: accounts payable, insurance claims processing, vendor onboarding, and HR document workflows.
We work with operations teams processing anywhere from 12,000 to 80,000 documents monthly. Most of those documents — invoices, purchase orders, insurance claims — contain personal data in the TDPSA's definition. Vendor names, employee IDs, claimant Social Security numbers, home addresses on delivery manifests. The data is incidental to the document's business purpose, but it's present, and the TDPSA doesn't carve out an exception for it.
This post is not legal advice, and your counsel should be your authoritative source on compliance obligations. What we can offer is the operational view — how the TDPSA's requirements actually land when your document processing pipeline is running 50,000 invoices a month.
What the TDPSA Actually Covers in Document Workflows
The TDPSA applies to any entity that conducts business in Texas or produces products or services consumed by Texas residents, and that processes personal data. "Personal data" under TDPSA is defined as any information that is linked or reasonably linkable to an identified or identifiable natural person — and it explicitly includes data about employees, contractors, and individuals in a business capacity.
That second point matters for AP teams. An invoice from a sole proprietor or a one-person LLC contains personal data by TDPSA definition: the person's name, address, and potentially a Social Security number on the W-9 on file. A delivery address on a purchase order that routes to an individual employee is personal data. An insurance claim is almost entirely personal data.
The three TDPSA obligations that most directly affect document processing pipelines:
- Data minimization: you may only collect and process personal data adequate, relevant, and reasonably necessary for the specified purpose
- Purpose limitation: data collected for invoice processing can't be repurposed for a different use without additional basis
- Data security: appropriate technical and organizational measures to protect personal data, considering the nature and scope of processing
Data Minimization in an Extraction Pipeline
Data minimization is where extraction systems get complicated. When you run an invoice through an extraction pipeline, the system reads the entire document. The question TDPSA poses: are you storing everything the model read, or only the fields your business process requires?
Consider a concrete scenario: a mid-size logistics company in Dallas processes 18,000 vendor invoices monthly. Their AP workflow needs six fields per invoice: vendor ID, invoice number, total amount, line items, due date, and GL code. Their extraction vendor, however, stores the full raw text of every document — including vendor contact names, billing addresses, and personal identifiers that appear in the document body but aren't needed for payment processing.
Under TDPSA's data minimization requirement, retaining that surplus personal data without a specific processing purpose creates exposure. The fix isn't technically difficult — configure extraction output to store only the fields your downstream process actually uses. But it requires deliberate configuration, not just accepting the extraction vendor's default output schema.
In Fieldiq, this is configurable per document type. You define the output schema — the structured fields you want extracted and stored — and the pipeline only persists those fields. The raw document image is used for extraction and then governed by your retention policy, not retained indefinitely as a searchable data store.
Retention Windows and Document Storage
The TDPSA doesn't specify retention periods — it requires that personal data be retained no longer than reasonably necessary for the processing purpose. That means you need a defensible basis for however long you're keeping extracted document data.
For AP teams, the retention question usually gets answered by other requirements first: IRS record-keeping rules suggest three to seven years for payment-related records (Publication 583 is the relevant guidance), state tax requirements can extend that, and audit windows for internal controls typically match or slightly exceed financial statement periods. Those existing obligations generally provide the TDPSA-defensible purpose for retaining structured AP data.
Where teams run into trouble is with the raw document files — the original PDFs and TIFF scans. These get ingested, extracted, and then... often just sit in a storage bucket indefinitely. Most organizations have a defensible reason to keep the structured extracted data for audit purposes. Fewer have a defensible reason to keep the original document images for five years after the payment was processed.
Our default configuration retains raw documents for 90 days post-extraction, then auto-deletes. Enterprise customers can configure this to match their specific audit requirements, but the default errs toward the TDPSA-minimization direction rather than indefinite accumulation. We're not saying 90 days is the right window for every operation — audit requirements genuinely vary — but indefinite retention without a stated purpose is what TDPSA is designed to address.
Claims Processing Has Additional Exposure
Insurance claims processing sits in a different position than AP because claims documents routinely contain sensitive categories of personal data under TDPSA — health information, financial account data, and in some workers' comp claims, biometric identifiers.
TDPSA defines sensitive data as a category requiring additional controls: explicit consent is required for processing sensitive data unless a statutory exception applies. Insurance processing generally falls under a contractual necessity exception (the insured entered a contract that requires claims processing), but the documentation requirements for that exception are non-trivial. Your legal team needs to confirm the exception applies and document the legal basis — not just assume it.
The practical extraction implication: when processing claims documents, you want the extraction output to be limited to the fields your claims workflow actually routes — claim number, policy number, incident date, covered amount, adjuster assignment. Personal health data that appears in a physician's letter attached to the claim but isn't a field your workflow processes is a minimization concern if your system stores it.
Processor Agreements and Your Extraction Vendor
Under TDPSA, if you engage a third party to process personal data on your behalf (which is exactly what an extraction vendor does), that relationship requires a data processing agreement. The DPA must specify: the nature and purpose of processing, the type of data involved, the duration, and the processor's obligations — including assisting with consumer rights requests and deletion obligations.
If your current extraction vendor (or your previous BPO provider) hasn't offered you a TDPSA-compliant DPA, that's a gap. We have a data processing addendum available for enterprise customers specifically addressing Texas TDPSA obligations. If you're evaluating document processing vendors and you're a Texas-nexus operation, DPA availability should be on your vendor checklist alongside integration support and accuracy claims.
Practical Steps for Operations Teams
A realistic compliance posture for document-processing operations under TDPSA doesn't require rebuilding your workflow from scratch. The gaps are usually configuration and policy, not infrastructure. Four things worth auditing:
- Map what personal data your documents contain — not just the fields you extract, but what's in the raw documents entering the pipeline
- Audit your extraction output schema — are you storing more personal data fields than your downstream process requires?
- Set and enforce retention policies — both for raw document files and for extracted structured data, with a documented purpose for each retention window
- Confirm processor agreements — with any vendor that touches the documents, including extraction, BPO, and storage providers
None of this replaces counsel review of your specific operations. TDPSA compliance is ultimately a legal question about your specific data processing activities. But the operational configuration decisions — what you extract, what you store, how long you keep it — those are where legal compliance meets extraction engineering, and that's a conversation we're set up to have with your team.