Local vs cloud PDF extraction: what actually leaves your computer?

"Local" and "cloud" get used as slogans. Buyers need a clearer sentence: which files are processed on your machine, which requests leave the building, and who can see document contents. This post is how we answer those questions for the offline PDF and Excel workflows we deliver, and which questions you should ask any vendor.

Manufacturing and finance buyers often raise the same concern: supplier pricing and ledger attachments should not sit in a random web tool by default. Local processing is how we respond without pretending every integration on earth is air-gapped.

Our site privacy page covers company-wide practices. This article stays on the product behaviour for document automation. For how the full package is scoped, see PDF and Excel workflow automation that runs on your PC.

Local by default

The application processes documents on your computer by default. That is the delivery model we use for extraction libraries as well: offline, custom Python tooling, which keeps recurring vendor cost low and keeps the files on the machine that already holds them.

For many accounting teams this matches how they already work. The PDFs land in a shared folder or mailbox export. The Excel master lives on a network drive or the same PC. The run produces CSV, Excel, XML, or another agreed file next to those inputs. No one has to upload a week of supplier bills to a third-party portal to get structured data out.

Local also helps with predictable cost. Cloud extraction APIs often price per page. When volume spikes at month end, the bill spikes with it. A configured local run scales with your machine time, not with someone else's meter.

The honest caveat: external requests only if configured

We do not describe the tools as "never uses any cloud." A custom workflow may make external requests if it is configured to do so. We explain the actual configuration during implementation. That sentence is intentional. Absolute "never" claims tend to be false the moment someone adds a mail notify, a webhook, or a one-off enrichment.

What we will not do is advertise a general cloud extraction API fallback as a product feature. In one engagement the original purchase order mentioned an external extraction API, and as a goodwill assurance for that client we promised that if local extraction ever did not work, an API fallback would be set up at no cost to them. That is a client-specific commitment. It is not something we sell as the default architecture.

Licensing without harvesting document contents

Licensing uses a machine fingerprint. That is how the temporary licence becomes a lifetime unlock after payment. It is not a back door into your PDFs.

As the product policy states today: customer documents are not used for monetization. The application does not collect document contents, workflow data, or usage analytics in the sense of shipping your invoices to us for training or resale. If a future policy change ever altered that, it would need to be written clearly. Right now the useful buyer line is: the run is built to work on your PC around your process.

What to ask any vendor

Use questions that force a specific answer, not a brochure paragraph.

• Where does the PDF file bytes go during a normal successful run?
• Which outbound hosts, if any, are contacted, and can the workflow run with those blocked?
• Is OCR or enrichment optional, and who pays if it is metered?
• Do you store sample files after a demo, and for how long?
• Is licensing tied to a machine, a user seat, or a cloud account?
• What happens to documents if support needs to debug a template?

Vague answers like "enterprise-grade security" are not answers. You want a data-flow sentence you could draw on a whiteboard.

Cloud extractors still have a place

A cloud API can be the right trial when every document is different and a person will review every result anyway. It is a weaker fit when the same vendor layouts arrive every week and you already keep Excel master data for checks. In that second case you want saved rules, master lookups, and an exceptions report on your own machine.

We also do not compete by saying cloud tools cannot fetch dates. They can. The gap we fill is the customer's agreed rules: which source wins, which mismatches become disputes, which calculations must match before a line is import-ready.

Demo files versus production files

Feasibility almost always starts with emailed samples. That transfer is under your control: you choose what to redact and when to send it. Production is different. Once the software is installed, the steady-state path should not require uploading every new vendor bill to our servers so we can "see" it.

If support needs a file to debug a recurring template issue, that should be an explicit share, not silent telemetry. Ask vendors whether debugging requires a permanent pipeline of live documents. Prefer a model where you attach a sample when something breaks.

Network controls worth testing

On a locked-down finance PC, try running a batch with outbound traffic denied except what you intentionally allow. If the workflow still completes and writes outputs, you have evidence for the local claim. If it fails, you have a concrete dependency to discuss before go-live, not after the first month-end.

How this shows up in day-to-day ops

After implementation, the goal is a workflow your team can run without routine developer involvement for every batch. Post-sales support exists and is scoped separately. The point of local, configured software is that routine runs should not need us online.

Windows 10 and 11 are the supported desktop platforms. Internal-use licensing matches how most SMEs deploy this class of tool: on the machines that already handle the books, not as a public multi-tenant service.

For company contact and general site privacy wording, start at our privacy page. For the product page that states local-by-default behaviour next to pricing and fit, use the workflow automation link above.

Where the files are processed is only half the decision. The other half is how you automate PDF data extraction and what you check before anyone posts the result.

FAQ

Do sample files for a quote leave our network?

You email samples for feasibility. Treat that like any vendor evaluation: send representative files, redact what you must, and ask how long samples are retained.

Is this a certification claim?

No. We describe behaviour, not ISO badges we have not put on this page.

Can a workflow notify someone by email?

Only if that is configured. Ask during scoping so the data-flow diagram stays honest.