When you implement document extraction, you're creating a new data category that didn't exist before: structured data derived from source documents, stored in your extraction system separate from the original files and separate from the ERP records those files fed. That derived data has its own retention question, and it's one that most organizations don't think about when setting up their document automation systems.
This post addresses the retention question across three document types — invoices, purchase orders, and insurance claims — and for two data categories: the raw document files (the original PDFs and TIFFs) and the extracted structured data (the JSON or database records that your extraction system produced). These are different retention questions with different regulatory and operational drivers.
As with TDPSA guidance, this is operational framing, not legal advice. Your counsel and your finance/compliance functions should sign off on actual retention schedules. What we're offering is the framework for having that conversation productively.
Three Drivers of Retention Decisions
Retention decisions are driven by three different pressures, and they often push in different directions:
Regulatory minimums: some data must be kept for a minimum period. IRS regulations under 26 CFR 1.6001-1 require businesses to maintain records supporting their tax returns for at least three years, with the general statute of limitations on assessment. For many payment-related documents, the practical standard is seven years — three years plus some buffer for amended returns or extended statutes in specific circumstances. State sales tax records carry their own requirements. Insurance records vary by state.
Regulatory maximums: privacy regulations like TDPSA (Texas) and CCPA (California) require that personal data not be retained longer than necessary for the specified purpose. Holding AP data for 20 years "just in case" isn't defensible under data minimization requirements when your audit window is seven years. There's a floor and a ceiling, and they're not the same number.
Operational reuse: some extracted data has genuine operational value beyond the original transaction. Vendor pricing history is useful for procurement analytics. Claims pattern data is useful for fraud detection. Invoice volume data is useful for cash flow forecasting. This reuse is legitimate but should be explicitly assessed — you should know which derived data you're keeping for operational use and which you're just not getting around to deleting.
Invoice Data: Two Different Objects, Two Different Windows
An invoice creates two objects in your extraction system: the original document file (PDF, TIFF, or email attachment) and the structured extracted record (invoice number, vendor, amount, line items, etc.).
The structured extracted record should be retained for as long as you need to support audit and reconciliation. For most AP operations, that's a 7-year window from the date of payment — matching the practical standard for payment-related tax records. This data is likely already stored in your ERP; the question is whether the extraction system also maintains a copy. If so, you have two retention schedules to manage for the same logical data. Our recommendation is to configure the extraction system to purge structured records after they've been confirmed as successfully pushed to ERP — keeping a copy in the extraction system adds storage cost and retention management overhead without adding audit value.
The original document file is a more interesting question. If your ERP is the system of record for the payment, and the structured extracted data in the ERP is complete and accurate, the original PDF may have limited audit value beyond what's already in the ERP record. The counter-argument: a dispute with a vendor or an audit question about a specific line item often requires producing the original invoice, not just the ERP record. The original document is the evidence; the ERP record is the ledger.
Our default configuration retains original invoice documents in the extraction system for 90 days, then auto-deletes. This assumes you have a document management system or your ERP has document attachment capability where the originals are stored for longer retention. If Fieldiq is your only copy of the original document, 90 days is not an appropriate retention window — you need to either extend it or establish a separate archival process.
Insurance Claims: Regulatory Minimums Vary by State
Insurance claim records are subject to state insurance department regulations, and these vary significantly by state and claim type. In Texas, for example, the Texas Department of Insurance requires that claim files be retained for five years after final disposition, or three years after the expiration of the applicable policy period — whichever is longer. California's requirements differ. If you're processing claims across multiple states, you need state-specific retention schedules, not a single national policy.
The additional complexity for claims is that the extracted structured data and the original claim document may have different retention needs. The structured data (claim number, policy number, incident date, settlement amount, adjuster assignment) needs to be retained for regulatory compliance. The original claim documents — including attached medical records, photographs, and third-party reports — may need to be retained under different rules that account for HIPAA (for health information), attorney-client privilege (for legal correspondence), or evidence preservation requirements if the claim resulted in litigation.
This is not a case where the extraction system should be setting retention policy. Claims retention is a legal and compliance question that requires your legal team's input for each claim type and jurisdiction where you operate.
A Framework for Setting Retention Schedules
For each document type and data category in your pipeline, the retention decision should answer four questions:
- What is the regulatory minimum? This is the floor. For invoices: generally three to seven years from transaction date depending on tax context. For claims: state insurance code requirements. Don't set a schedule below this.
- What is the audit window for your internal controls? If your internal audit program covers three years of transactions, your operational retention minimum is three years plus whatever buffer your auditors require for period-end documentation.
- What is the operational reuse purpose, if any? If you're retaining extracted data for analytics or ML model improvement, document that purpose explicitly and set a separate retention schedule for that use case. Don't co-mingle audit retention with analytics retention.
- Is this data also stored elsewhere? If the ERP is the authoritative store of the structured data, the extraction system doesn't need to be a long-term archive. Configure it to purge after confirmation, and let the ERP's retention schedule govern.
Configuring Retention in Fieldiq
Retention configuration in Fieldiq operates at three levels: global defaults, document-type overrides, and individual document holds.
Global defaults set the system-wide baseline: raw document retention window and structured data retention window. These apply to all documents unless overridden. Our out-of-the-box defaults are 90 days for raw documents and 12 months for structured extraction data — deliberately conservative defaults that push organizations toward intentional retention decisions rather than indefinite accumulation.
Document-type overrides let you set different schedules per document category. Invoices might be configured for 90-day raw retention with structured data purged after ERP confirmation. Claims might be configured for 365-day raw retention pending your legal team's guidance on longer archival. Regulatory filings might have a five-year hold on structured data matching your compliance team's schedule.
Individual holds let you preserve a specific document and its extracted data indefinitely — useful when a document is subject to a legal hold or is part of an active audit inquiry. Holds override all automatic deletion schedules until explicitly released.
We're not saying there's a single right answer to how long you keep document data — the retention question is genuinely organization-specific and requires legal and compliance input. What the configuration framework gives you is the ability to implement whatever schedule your team determines is correct, with automatic enforcement, without relying on manual deletion processes that inevitably accumulate backlogs.