Workspace administration

This chapter covers the settings that shape how your workspace behaves day to day: who can sign in and with what role, how your account is protected, what's recorded in the activity log, how numbers, dates, filenames and folders are handled, how long documents are kept, your privacy rights, and how to close a workspace for good. Most of these live under Settings → Workspace and Settings → Security in the sidebar.

Roles

Every person who signs in to DocReadi has one role, which controls what they can see and do:

• Reviewer (tenant_reviewer) — the default role for anyone added to a workspace. Can view and approve/reject documents, run reports, use test extract, and manage their own sessions and 2FA. Cannot change settings, manage connections, or see the activity log — the one exception is the Email log, which a reviewer can view read-only.
• Admin (tenant_admin) — everything a reviewer can do, plus workspace settings: document handling, feature flags, entities, counterparties, GL accounts, custom templates, the Sync cluster (connections, inbox/outbox, Xero activity), webhooks, API keys, the activity log, and the subscription page.
• Firm admin (firm_admin) — the same permissions as an admin, used by accountants and firms managing more than one client workspace under a shared login and a pooled credit balance. See Billing and credits for pooled billing.

Bank account numbers and IBANs follow the role. Admins and firm admins see the full number everywhere in a workspace they operate. A reviewer, and a reviewer API key, sees only the last four digits unless an admin has granted access under Bank number access.

A handful of screens — the Models registry and provider balances — are restricted to DocReadi's own platform operators and aren't available to any workspace role. If you need one of those, contact support.

Who has access

Settings → Users (admins only, under Security) lists People in this workspace: each person's email, their Role, and the methods they Signs in with. Use it to check who can open the workspace.

Adding teammates

New logins are provisioned by DocReadi, not self-served from within a workspace today. To add a teammate:

1. Contact support with the email address and the workspace they need access to.
2. They receive an invite link by email. Opening it lets them set a password and sign in directly — no separate approval step.
3. Tell support what role the new person needs (reviewer or admin); the default for a new login is reviewer.

If someone already has a DocReadi login for a different workspace (for example, an accountant who works across several clients), ask support to link their existing login to the new workspace instead of creating a second one — that keeps one email/password combination working everywhere they have access, with the tenant switcher (see Getting started) to move between them.

Two-factor authentication

Settings → Security → Two-factor auth lets you add a 6-digit code from an authenticator app (Google Authenticator, 1Password, Authy, etc.) to your own sign-in. It's optional and per-user — each person on the workspace enrols individually.

To enrol:

1. Open Two-factor auth and start setup.
2. Scan the QR code with your authenticator app.
3. Enter the 6-digit code it generates to confirm. DocReadi checks the code before turning anything on, so a typo just asks you to try again.
4. You're shown a set of one-time recovery codes exactly once — save them somewhere safe. Each code works once, if you ever lose access to your authenticator app. DocReadi never shows them again.

Once enrolled, every sign-in asks for a code after your password. To turn 2FA off, go back to the same page and confirm with a current code (or a recovery code) — this prevents someone who's briefly gained access to your browser from disabling your second factor.

If you sign in with Google or Microsoft (see Getting started) and haven't turned on DocReadi's own two-factor auth, this page adds a note. It says either that your provider account asked for a second factor on your last sign-in, or that DocReadi couldn't see one and you can turn it on in your provider account or add DocReadi's code here. DocReadi shows the code screen after a provider sign-in unless the provider proves it asked for a second factor.

Active sessions

Settings → Security → Active sessions lists every device currently signed in as you — issue time, last used, IP address, and a short device/ browser description. The device you're using right now is marked.

• Revoke on a single row signs that device out immediately.
• Sign out everywhere else revokes every other session in one action without logging you out of the page you're on — useful after a password change or if you've left a device signed in somewhere you don't control.

This page only shows and manages your own sessions — there's no cross-user session view.

Bank number access

Settings → Security → Bank number access controls who, besides admins, can see full bank account numbers and IBANs. By default a reviewer sees only the last four digits (for example ••••7890). Here an admin can lift that mask for one named person or key, for a limited time. You need the Admin or Firm admin role to open the page.

• Who can be granted. One reviewer in this workspace, or one reviewer API key of this workspace, per grant. Admins and firm admins aren't listed, because they already see full numbers, and you can't grant access to yourself.
• What a grant does. The grantee sees the full number in this workspace only, on every screen, report, export and API response they open.
• Granting. Under Grant access, choose Who, choose Expires (in 30 days, in 90 days or in 1 year; there is no "never"), enter a Reason, and select Grant access. The reason is required and appears in the Activity log.
• Revoking. Each active grant has a Revoke… control that asks for a reason, then ends access straight away. Ended grants, whether revoked or expired, are listed under Ended grants, collapsed.
• Activity log. Grants, revocations and expiries are recorded (bank_access.granted, bank_access.revoked, bank_access.expired). A daily summary event (bank_access.daily_rollup) counts the requests on which the grantee was served full numbers.
• Plans and API. Available on every plan. Grants are managed only in the app; there is no API endpoint for them.

A reviewer API key with a grant shows a Full bank numbers badge on the API keys page. Any API response that applies the bank-number rule includes an X-Bank-Numbers header, full or masked, so an integration can tell which it received.

Bank account numbers can be personal information and are the target of payment-redirection fraud, so grant access only to people or systems whose work needs it.

Activity log

Settings → Logs & tools → Activity log (Admin role) shows the last 200 events in your workspace: sign-ins, document approvals, API key creation, webhook changes, 2FA enrolment/disable, and similar account activity — newest first. Use the filter strip to narrow by event kind, actor, or a date range. Each row can be expanded to see the full event detail. This is the place to check "who did this" for a compliance review or to investigate an unexpected change.

Number and date formats

Settings → Workspace → Number and date formats controls how amounts and dates are shown across the web UI, reports, exports, and WhatsApp replies.

• Date rendering is set per workspace — pick the format (e.g. day/month/ year vs month/day/year) that matches how your team reads dates. A live preview shows today's date in the selected format. The same format is what you type into date fields when you correct a document in Edit Fields (see Reviewing documents).
• Number format (thousands and decimal separators) is a platform-wide setting; an admin sees a preview of the active format but changing it is handled by your platform operator.

Filename rename, folders and re-filing

Settings → Workspace → Document handling groups the rules DocReadi applies to every incoming document:

• Filename rename — off by default, so an uploaded file keeps its original name. Turn it on to auto-rename using a template built from placeholders (e.g. {party1} - {invoice_number}), with a live preview of what a real filename would look like. Unsafe characters are stripped automatically and the file extension is always preserved. You can choose when the rename happens (on upload, or once extracted values exist).
• Default upload folder — new documents can be filed automatically into a folder built from a pattern (e.g. {party1}/{date}), mixing literal text with placeholders and / to nest folders. Applies to uploads, the API, WhatsApp, and Inbox sources. Choose whether documents are only filed at upload (extraction placeholders are still empty at that point), or re-filed once extraction or approval fills those values in. A folder you pick or move by hand is never overwritten by auto re-filing. Leave the pattern blank to keep documents unfiled.
• Tax jurisdiction — the country whose VAT rules the validator checks extracted VAT rates against (see How processing works). Set this to the country most of your invoices are taxed under; multi-country workspaces should choose Unspecified to widen the plausible-rate band instead of flagging every non-local rate as unusual.

Currencies you work in

Also on the Document handling page: many documents show only a symbol or a name that several currencies share — $, ¥, kr, "pesos". The Currencies you work in card tells DocReadi which currencies your workspace actually deals in, so it can settle those cases. You need the Admin role to change it.

The card lists every current ISO 4217 currency by code and name, with a search box to find one. Select all and Select none tick or clear the whole list; when your tax jurisdiction has its own currency, an Only … button (for example Only ZAR) ticks just that. Click Save to apply. The line next to Save shows what is active. Every currency is ticked until you change it, and you can't save with none ticked — the card asks you to tick at least one, because with none enabled every document would go to review.

How DocReadi uses the list:

• For a shared symbol or name, the seller's country decides first. If that still leaves a choice, only the ticked currencies are considered, and when exactly one is left it is used. For example, in a workspace that works only in USD, a bare $ is read as USD. When the ticked list (rather than the seller's country) settled it, the Currency field is marked in amber so the reviewer can see it was worked out rather than printed. A $ invoice from a US seller is simply read as USD, with no mark; a $ invoice from, say, an Australian or Canadian seller is read as that country's dollar and marked in amber, because it may have been billed in US dollars.
• A currency code printed on the document, such as EUR, is always kept as printed.
• A document in a currency you haven't ticked is never switched to another currency. It goes to review with Currency isn't one your workspace works in. For example, a $ invoice from a Mexican seller in a USD-only workspace reads as Mexican pesos, which are switched off, so the currency is set to MXN and the document is flagged — it is never read as USD.

Changing the list doesn't touch documents already processed until they are checked again — click Re-validate, or save a change in Edit Fields (see Reviewing documents).

OCR routing for specific document types

Also on the Document handling page: DocReadi normally decides per document whether to read it as native text or run it through OCR (see How processing works). If a particular document type keeps losing its tables or coming out garbled on the standard path — municipal and utility account bills are the known case — you can override that decision for the whole type instead of living with it.

Always use OCR for selected document types lists every built-in document type as a checkbox. Tick a type and every document DocReadi classifies as that type is read by the OCR engine, skipping the standard text extraction entirely. Nothing is selected by default. OCR is billed per page, so treat this as a targeted fix for a type you've actually seen the problem on, not a blanket setting.

A parser you choose explicitly at upload — including when you reprocess a document — always wins over this setting for that document, with one exception: a scanned PDF (no real text layer) is always read by OCR, whichever parser was chosen.

Retention

Also on the Document handling page: DocReadi automatically deletes this workspace's documents (and their extracted records, usage history, processing errors, and backups) once they pass a configurable retention window. The window you set here applies to your workspace only — every other workspace on DocReadi keeps its own, set separately.

DocReadi's own database backups are kept for up to 365 days and then deleted, so data you delete can remain in encrypted backups until they expire (see the hosting page at /legal/hosting).

If your workspace hasn't set a window of its own, the card tells you so and shows the default it's currently following instead (7 years unless DocReadi's operator has changed the platform-wide default). Saving a value on the form pins the window to your workspace from then on.

Set it to 0 to disable automatic deletion entirely for your workspace — useful for long-hold legal or audit needs, though storage growth then becomes your responsibility. Deletion is permanent — there is no recycle bin. An individual document can also be flagged to retain indefinitely from the document viewer, which exempts just that document from the sweep regardless of the workspace window.

This exists because data-protection law (GDPR, POPIA and similar regimes) requires personal data to be kept no longer than necessary for the purpose it was collected for — "keep everything forever" isn't a defensible default.

Due-date arithmetic

Also on the Document handling page: extraction only ever reads a due date the document actually prints — it doesn't calculate one. Many invoices print an invoice date and payment terms (for example "30 days net") but no due date as such. The Due-date arithmetic card controls what happens next:

• On (the default): when a document has an invoice date and printed payment terms but no printed due date, DocReadi fills the due date as invoice date plus the stated terms, and marks it as derived rather than read. Only terms the document itself prints are used — this never draws on the workspace's Default payment terms assumption below, and it never overwrites a due date the document does print. The terms are read with their basis, not just their number:

  • "30 days net" or "Net 45" — invoice date plus that many days.
  • "30 days from statement" or "30 days from month end" — the last day of the following month.
  • "Net 30 EOM" or "30 days after the end of the month" — the last day of the invoice month plus 30 days.
  • "Due end of month" — the last day of the invoice month.
  • "25th of the following month" — that day of the following month.

  Terms DocReadi cannot read cleanly — for example "30 days month-end", "45 days from statement" (not a whole number of months), or a document that prints two different terms — still leave the due date empty rather than guessed. That applies wherever the document prints such terms, even if they were not picked up into the Payment Terms (as printed) field. A derived due date is still marked as calculated rather than read.

• Off: a document without a printed due date is stored with an empty due date.

This also covers custom templates, but only when the template's fields use the exact names due_date, invoice_date and payment_terms_days — fields with any other names are never touched.

This is separate from — and runs before — the export-time fallback described next, which only ever fills a due date in an exported file, never in the stored document.

Default payment terms

Also on the Document handling page: some documents have no due date at all, printed or derivable — no invoice terms to compute from. Some export destinations — Xero in particular — require a due date before a bill can be approved, so DocReadi's exports fill one in rather than leaving it blank: the Xero Bills CSV download (see Reports and exports) and the Xero-formatted delivery bundle both apply the same fallback.

The fallback applies only to documents that print no payment terms at all. When a document prints its own terms but has no due date, the export works the date out from those terms with their basis — plain days ("30 days", "Net 45"), month end, "30 days from statement", "Net 30 EOM" or a day of the following month, as described under Due-date arithmetic — and never uses the default below. If the printed terms cannot be read cleanly, the due date stays empty in the export too, because an assumed date would be the wrong one. Fill the due date in Edit Fields before exporting if your destination needs one.

The fallback is layered, and the stored document is never changed — the assumption only ever appears in the exported file:

1. A due date on the stored document always wins — whether it was read directly off the document or filled in by Due-date arithmetic above.
2. Otherwise, the counterparty's own Payment terms (a basis plus a number, set on its record under Master data) wins.
3. Otherwise, the workspace's Default payment terms setting applies.

The Default payment terms card is a preset menu:

Choose Custom... to show a "Counted from" menu and a number. The bases are days after the invoice date, the end of the invoice month (no number), the end of a following month (the number is months), days after the end of the invoice month, a day of the following month, and a day of the invoice month. The number can be 0 to 365 — days, months or a day of the month depending on the basis. If the pair is not valid the card shows the reason and saves nothing. The card's Active line shows what is in force.

A new workspace that has never saved this card starts on 30 days from month end when it looks South African — it pays in ZAR through Paystack, has SARS tax-invoice details, or one of its own entities has a South African VAT number — and on Net 30 otherwise. A workspace that existed before payment terms had a basis keeps Net plus its saved number (30 if it never saved one).

Privacy rights requests

Anyone — not only a signed-in workspace member — can submit a data-subject rights request at docreadi.com/privacy/rights, without needing to log in. The form covers:

• Access — get a copy of the personal data DocReadi holds about you.
• Deletion — erase personal data DocReadi holds about you.
• Correction — fix inaccurate personal data.
• Restriction — limit processing of your data.

Submit your email, optionally your name and the workspace slug (so the request can be routed to the right workspace), and a short description. You'll get an email confirmation as a paper trail. DocReadi aims to resolve requests within 30 days.

Closing a workspace

Settings → Workspace → Close workspace (Admin role) is where you permanently close a workspace. What you see on the page depends on how many workspaces you have access to:

• If you operate more than one workspace — for example a firm admin managing several client workspaces under one login — the closure form is available directly on the page. Type the workspace's slug to confirm (shown on the page), then submit. This is meant for closing one of several workspaces you manage, not your only one.
• If this is your only workspace — the page explains that closing it would end your account entirely, and points you to support instead of showing the form. Closing your only workspace is account-ending, so it stays a human conversation rather than a one-click action.

Once a closure is actioned (either self-serve or via support):

• The workspace is immediately deactivated — logins stop working for everyone in it, and Inbox sources and Outbox deliveries stop.
• It stays in a soft-deleted state for 30 days, during which the closure can still be reversed by contacting support before the purge date.
• After the 30-day window, everything is purged permanently: documents and their stored files, extraction results, counterparties, entities, and connection credentials.
• Two things are kept even after the purge, by design: the activity log — including who initiated the closure and when, so the date can be verified afterwards — and any tax invoices DocReadi issued to the workspace, which are retained for the legally required period. Nothing else survives.

If you want a copy of your data first, export it from Reports before closing — closure does not email you an archive.

Contacting support

For anything this chapter points you to — adding a teammate, closing a workspace, or any account issue you can't resolve from Settings — email [email protected].

See also: Billing and credits for the subscription page and pooled billing, and Troubleshooting for the pipeline errors page and common validation failures.

Looking for the developer/API reference? See /api/docs-guide. Can't find an answer? Email [email protected].