Connect the finance inbox without handing over the keys.

When you wire up QuickBooks Online, Xero, or Sage Intacct, PODetectopens that vendor’s official consent screen in front of you. You’ll see the exact list of scopes we’re asking for, written in the vendor’s own words, before you click Authorize. We never see your password, and we never store it — OAuth runs entirely on vendor-issued tokens.

The connection step reads the data the audit needs (chart of accounts, recent GL, vendor master) and nothing else. If the vendor offers a narrower read-only scope, we request the narrow one. If a future feature needs a wider scope, the token is re-consented on the vendor’s screen — you’ll see the new scope list and approve it again, not us.

Every auto-post runs against a post-only token that is scoped to a single vendor and a single ledger. The token can write approved journal entries against that one connection and nothing else — it cannot read other workspaces, cannot touch payroll, cannot change your vendor master, and cannot be promoted to a tenant-wide admin scope.

The connection is initiated by an Admin, Standard+, or AP Clerk seat on your workspace — never a global service account, never a shared password. Any vendor we connect to on your behalf is recorded in the integrations matrix alongside the exact scopes and the redirect URI we registered with that vendor.

Every invoice leg — the upload to our processor, the round-trip through the OCR model, the OAuth exchange with the ledger, and the journal-entry post — runs over TLS. We do not accept unencrypted uploads, and we do not initiate unencrypted outbound calls to a connected ledger.

Our full security posture (encryption at rest for stored Customer Content, role-based access controls, audited production access, and how we respond to a material incident) is described in the Privacy Policy § Security.

We use the original invoice PDF or image long enough to extract the fields the audit needs (vendor, invoice number, line totals, tax, PO match) and to surface any exception. After that, we keep the structured audit signals — the exception record, the digest entry, the reversal ticket if one exists — not the bulk PDF.

Full PDFs are held for the duration of your active subscription, plus a thirty (30) day post-closure window so a cancelled workspace can be restored with its audit context intact. After that window the original PDFs are purged and only the structured audit signals remain, until they age out under the retention rule in Section 6 below.

An auto-post only lands in the ledger after the same five rules pass on a clean invoice. Anything that fails a rule — vendor-master drift, a missing PO match, a duplicate recurring charge, a sales-tax anomaly, or an out-of-band total — is held in the reversal queue and never posts against your books.

Flagged exceptions are reviewed by the controller and AP team on your side, on the daily digest channel. PODetect does not employ a third-party reviewer, a salesperson, or an offshore annotation team to look at your invoices. You and your AP team are the only humans who see the underlying content; the thirty-day reversal window is the safety net if a flagged item later turns out to require one.

Invoice body, PO lines, and the daily digest archive are held for the duration of your subscription and purged within thirty (30) days of cancellation. The audit trail never outlives the data it audits — when the underlying records age out, the trail ages out with them.

If you need an earlier deletion of a specific vendor’s records, ask on the daily digest channel or send a note through the Contact form and we’ll purge that vendor’s audit material within the same thirty-day window. Aggregated, anonymized telemetry (counts that cannot reasonably be linked back to a Customer or an individual) may be retained longer for product analytics, as described in the Privacy Policy § Data Retention.