Artificio's Data Views: Turning a Folder of Extracted Documents Into a Live, Queryable Table Without Writing a Single Line of SQL

Picture a procurement analyst on a Tuesday morning. She has just finished running 2,000 supplier invoices through an intelligent document processing platform. The extraction worked. Vendor names, invoice numbers, line items, payment terms, tax amounts, due dates, all pulled out with high accuracy. Then the platform hands her the result: a zip file containing 2,000 JSON documents.

Now what?

She needs to answer a simple question from her manager: "Which vendors are we paying on net 15 terms when our standard is net 45, and how much is that costing us in lost float?" The data to answer that question is sitting right there in the extraction output. But between her and the answer stands a wall of work. Someone has to parse those JSON files, flatten the nested structures, load everything into a database or a spreadsheet, deal with the invoices where a field came back empty, and only then start filtering. She is a procurement analyst, not a data engineer. So she files a ticket with IT, and the answer her manager wanted by Friday arrives in three weeks.

This is the quiet failure mode of most document extraction tools. The extraction itself gets all the attention, the accuracy benchmarks, the model comparisons, the demo videos. What happens after extraction gets almost none. And after extraction is where the actual business value lives. Data Views is Artificio's answer to that gap. It takes the structured fields pulled from hundreds or thousands of documents and turns them, instantly, into a live table you can filter, sort, search, group, and export. It behaves like a spreadsheet crossed with a lightweight database, and it requires zero SQL, zero scripts, and zero data engineering.

The Gap Between "We Extracted Your Data" and "Your Data Is Usable"

Most IDP platforms treat extraction as the finish line. You upload documents, the model does its work, and you receive output in one of a few familiar formats. Maybe it is a JSON blob per document. Maybe it is a CSV export you trigger manually. Maybe it is a webhook payload that fires into some endpoint your team was supposed to build.

All of these outputs share a common trait. They are raw material, not finished product. A JSON file is useful to a developer writing integration code. It is useless to a procurement manager who wants to see all invoices from a specific vendor above $10,000, dated in the last quarter. That manager does not think in key-value pairs. She thinks in rows, columns, filters, and totals. The distance between what the platform delivers and what she needs is real work, and someone has to do it.

In practice, that work usually takes one of three shapes, and none of them are good.

The first shape is the spreadsheet shuffle. Someone exports a CSV, opens it in Excel, and starts cleaning. Column headers do not match across batches. Dates arrive in three different formats. Currency fields include symbols in some rows and not others. By the time the sheet is usable, it is already stale, because 300 new invoices arrived while the cleanup was happening. Every refresh means repeating the whole ritual. Version confusion follows quickly. Three people end up with three slightly different copies of "invoices_final_v2_ACTUAL.xlsx" and nobody trusts any of them. 

The second shape is the internal build. Engineering gets pulled in to stand up a database, write ingestion scripts, and maybe bolt a BI tool on top. This works, eventually. It also takes weeks or months, consumes engineering capacity that was supposed to go toward the product roadmap, and creates a fragile pipeline that breaks the moment the extraction schema changes. Add a new field to your invoice template and someone has to update the ingestion script, migrate the table, and adjust the dashboard. The maintenance burden never goes away. It compounds.

The third shape is the most common and the most damaging: nothing happens at all. The extracted data sits in storage, technically available, practically invisible. Teams keep making decisions from partial information because getting to the full picture is too much friction. The company paid for extraction and received a folder of files it never looks at. The ROI conversation at renewal time gets awkward.

Competitor tools leave customers stranded at exactly this point. The extraction demo was impressive. The pilot went well. Then the platform hands over the raw output and wishes everyone luck. The gap between extraction and usability becomes the customer's problem, and the customer often lacks the resources to close it.

What Data Views Actually Does

Data Views closes that gap at the platform level. The moment your documents finish processing in Artificio, the extracted fields do not just land in a file somewhere. They populate a live table inside the platform, structured, typed, and immediately interactive.

Think of it as the layer that sits between raw extraction and every downstream use of the data. Each processed document becomes a row. Each extracted field becomes a column. Vendor name, invoice number, invoice date, due date, subtotal, tax, total, payment terms, PO reference, line item counts. Whatever your extraction schema defines, the table reflects.

And because Artificio controls both the extraction and the table, the two stay in sync automatically. When a new batch of documents finishes processing, the rows appear. When you refine your extraction schema to capture a new field, the column shows up. There is no ingestion script to update, no ETL job to babysit, no schema migration to schedule. The pipeline that other teams spend weeks building simply does not need to exist.

The table itself behaves the way modern users expect a data tool to behave. You can filter on any column, and filters understand the data type they operate on. Date columns get date range pickers. Numeric columns support greater-than, less-than, and between conditions. Text columns support contains, equals, and starts-with matching. You can stack filters, so "vendor equals Meridian Supply AND total greater than 10,000 AND invoice date within Q2" takes about fifteen seconds to set up. Sorting works on any column, ascending or descending, with multi-column sort for cases like "sort by vendor, then by due date within each vendor."

Search runs across the entire table, so if all you remember is a PO number or a fragment of a vendor name, you can find the row in one keystroke sequence. Column visibility is configurable, so the accounts payable team can look at a payment-focused view while procurement looks at a terms-and-pricing view of the same underlying data. Saved views make those configurations persistent. Set up your filters and columns once, name the view, and return to it every morning without rebuilding anything. 

Every value in the table stays linked to its source document. Click a row and you can open the original invoice, see the extracted fields highlighted on the page image, and verify anything that looks off. This matters more than it sounds. A number in a spreadsheet is an assertion. A number linked to the exact region of the source document it came from is evidence. When finance asks "are you sure about this figure," the answer is one click away instead of a forensic exercise.

A Concrete Walkthrough: 2,000 Supplier Invoices, One Afternoon

Abstract descriptions only go so far, so let us walk the procurement scenario end to end and put real numbers on it.

A mid-sized manufacturer receives roughly 2,000 supplier invoices per month across about 340 active vendors. Invoices arrive as PDFs by email, as scans from regional offices, and occasionally as photos taken on a warehouse phone. The procurement team wants visibility into payment terms, early payment discount opportunities, and spend concentration by vendor. Today that visibility does not exist, because the data lives inside 2,000 individual documents.

The team routes the monthly invoice inflow through Artificio. The extraction schema captures vendor name, vendor tax ID, invoice number, invoice date, due date, payment terms, currency, subtotal, tax amount, total amount, PO number, and a line item table for each invoice. Processing 2,000 documents completes well within the day. So far, this is the part every IDP vendor can demo.

Here is where the paths diverge. On a typical platform, the team would now be staring at that folder of JSON files. On Artificio, they open Data Views and the table is already there. Two thousand rows, twelve-plus columns, fully interactive.

The manager's question from the opening of this post takes about a minute to answer. Filter payment terms to "Net 15." The table collapses from 2,000 rows to 87. Sort by total amount descending. The top of the list shows that just four vendors account for over 70 percent of net 15 spend. Group by vendor, sum the totals, and the analyst can see exactly how much cash is leaving the building 30 days earlier than the company's standard terms require. She exports the filtered view to Excel, drops it into an email, and the renegotiation conversation with those four vendors starts that week. Not in three weeks. That week.

The same table answers the next five questions without any additional setup. Which invoices are due in the next 10 days? Date range filter on the due date column. Which vendors offer early payment discounts we are not capturing? Filter the terms column for discount language, compare against actual payment dates. Are any vendors sending duplicate invoices? Sort by vendor and invoice number, and duplicates sit next to each other, plain to see. Where is our spend concentrated? Group by vendor, sort by summed total, and the top 20 list writes itself. Did anything come through with a missing PO number? Filter that column for empty values, and there are the 43 invoices that need chasing before they hit the approval workflow.

Each of these would have been a separate request to IT, a separate spreadsheet exercise, or a question that simply went unanswered. With the live table, each is a fifteen-second filter operation performed by the person who actually needs the answer. That difference compounds daily. Teams that can interrogate their own data ask more questions, catch problems earlier, and stop treating data access as a scarce resource to be rationed.

There is a subtler benefit hiding in this workflow too. Because the table refreshes as new documents process, it is never stale. The view the analyst checks on the last day of the month includes the invoice that arrived that morning. Monthly reporting stops being a snapshot ritual and becomes a glance at a screen that was already current.

Why "No SQL Required" Is a Bigger Deal Than It Sounds

The phrase "no SQL required" can sound like a minor convenience, the kind of thing every no-code tool claims. In the context of document data, it is structural, and it is worth unpacking why.

SQL itself was never really the barrier. Plenty of analysts can write a SELECT statement. The barrier is everything that has to exist before a SELECT statement returns anything useful. You need a database. You need a schema that matches your extraction output. You need an ingestion process that loads new documents as they arrive, handles failures, and deals with fields that came back empty or malformed. You need someone to maintain all of it when the schema evolves. That is not a query problem. That is an infrastructure problem, and infrastructure problems belong to engineering teams with backlogs measured in quarters.

Data Views removes the infrastructure problem, not just the query syntax. The database exists because the platform provides it. The schema matches the extraction because they are the same system. Ingestion is not a process anyone built. It is just what happens when a document finishes processing. The empty-field edge cases surface as visibly blank cells you can filter for, instead of silent nulls that break a downstream script at 2 a.m.

This shifts who can work with document data inside an organization, and that shift matters more than any individual feature. When accessing extracted data requires engineering effort, access gets rationed. The loudest requests get served. Everyone else waits or gives up. When accessing extracted data requires opening a browser tab, access becomes universal. The AP clerk, the procurement analyst, the auditor doing a spot check, the CFO who wants to see one number before a board call, all of them work from the same live table, each with their own saved view, none of them waiting on anyone.

There is also a data quality feedback loop that only emerges when non-technical users can see the data easily. When extraction output goes straight into a pipeline that nobody looks at, extraction errors hide until they cause damage downstream. When output lands in a table that domain experts scan every day, errors get spotted fast, because the person looking at the vendor column knows the vendor names. She notices "Meridian Suply" immediately. A script never would. Data Views turns every daily user into a quality checkpoint, and correction happens at the source, with the original document one click away for verification.

Not an Island: How Data Views Feeds the Rest of the Artificio Ecosystem

A live table is valuable on its own. It becomes far more valuable as the connective tissue between extraction and everything downstream, and this is where Data Views stops being a feature and starts being an architectural layer.

Inside Artificio, the data sitting in a view is the same data available to every other part of the platform. Forms can read from it and write back to it. When a human reviewer opens a validation form to check a low-confidence extraction, the corrected value flows back into the view, and everyone looking at that table sees the corrected number from that moment forward. There is no separate "review copy" that drifts away from the "real copy." One record, many surfaces.

Dashboards build on views the same way. Spend by vendor over time, invoice volume by document type, average days-to-due-date, exception rates by supplier. These visualizations draw from the live table, which means they update as documents process, without a refresh job or a nightly sync. The chart the CFO sees and the row-level table the analyst filters are two lenses on one dataset. When the CFO asks about a spike in the chart, the analyst filters the view to that date range and has the underlying invoices on screen in seconds.

Then there is the outbound side. Everything in a Data View is reachable through the API, with the same filters available programmatically that users apply in the interface. Your ERP integration does not need to parse raw extraction output. It queries the view for "approved invoices, not yet synced, total under auto-approval threshold" and receives clean, structured records ready for posting. Scheduled exports push filtered slices to wherever they need to go, a CSV to a shared drive for the legacy reporting process, a payload to a webhook that kicks off a payment run, a feed into the data warehouse where the analytics team joins document data against everything else the company knows.

For teams running SAP or another ERP as the system of record, this layering matters. The ERP should receive verified, structured, decision-ready records. It should not be the place where messy extraction output gets sorted out. Data Views acts as the staging and verification layer where document data becomes trustworthy before it touches the system of record. Exceptions get caught in the view, corrected against the source document, and only then move downstream. The ERP stays clean, and the audit trail of what was corrected, when, and against which document lives in the platform.

The same pattern extends across Artificio's product line. AP Studio leans on this layer for invoice workflows. APRecon works from tabular views when matching supplier statements against ledger entries. The Extract API populates views for teams building their own applications on top. One consistent answer to the question "where does my extracted data live and how do I use it," regardless of which door you entered through.

What This Looks Like Beyond Procurement

The invoice scenario is the easiest to picture, but the pattern applies anywhere documents arrive in volume and the value lives in comparing them, not reading them one at a time.

A logistics operation processing bills of lading gets a live table of shipments, carriers, weights, origins, and destinations. Filtering by carrier and date range turns rate auditing from a quarterly project into a standing view someone checks weekly. A mortgage team extracting income data from bank statements and tax documents gets a per-applicant table where underwriters filter for missing documents and out-of-range figures instead of paging through PDFs. A university admissions office processing transcripts and identity documents gets an applicant-level view where the registrar filters for unverified records and incomplete files, and the follow-up list generates itself. A clinical operations team extracting data from trial documentation gets a queryable record of site submissions, filterable by site, date, and completeness, ready for the next monitoring visit.

In every case, the shape of the win is identical. The documents were always full of answers. The answers were just locked inside individual files, and the cost of assembling them into something comparable was high enough that nobody did it. Drop the assembly cost to zero and the questions start getting asked.

The Real Measure of an Extraction Platform

Extraction accuracy is table stakes now. The leading platforms all extract well, and the accuracy race is producing diminishing returns that customers can barely perceive. The differentiation has moved downstream, to a simpler and harder question: how quickly does a processed document become a business decision?

Measured that way, a folder of JSON files scores poorly no matter how accurate the extraction was. The data is correct and inert. It waits for engineering effort that may never be scheduled. A live, filterable, connected table scores differently. The 2,000 invoices processed this morning are answering questions this afternoon, feeding the dashboard this evening, and syncing to the ERP overnight, and nobody wrote a line of code to make any of that happen.

That is the standard worth holding your document platform to. Not "can it read my documents," because they all can. Ask instead what happens in the first ten minutes after extraction finishes. If the answer involves a zip file and a plan to involve IT, the platform stopped short of the finish line and left the last, hardest mile to you. If the answer is a table you are already filtering, you are working with a platform that understood what the extraction was for in the first place.

Artificio built Data Views because extracted data that nobody can use is indistinguishable from data that was never extracted. If your team is sitting on a backlog of processed documents and a longer backlog of unanswered questions, a live table is closer than you think. Bring a batch of your real documents, run them through, and watch how fast "we extracted your data" turns into "here is your answer."