Greenbar Pay

How we protect your data

Greenbar Pay processes invoices and vendor data on behalf of your organization. This page describes the technical and operational controls we use to keep that data isolated, auditable, and protected from document-borne threats.

In development

Pay enters early access in late Q4 2026

Pay has not launched yet. The controls on this page are implemented in the product we are taking into early access — they describe how Pay will handle your data from day one, not a service currently processing customer invoices.

Join the Pay waitlist

Scope note

This page applies to Greenbar Pay, our cloud accounts-payable product. GreenBar's other tools — Clearing in particular — are local-first desktop software that process your data on your own machine and send nothing to our servers. They have separate, simpler privacy characteristics described in our Privacy Policy.

Tenant isolation

Every database query in Greenbar Pay runs inside a transaction that pins the active organization to the database session via a Postgres GUC. Row-Level Security is enforced at the database layer — not just in application code — so a misconfigured query cannot return another organization's records, even in the event of an application bug.

Postgres Row-Level Security enabled and forced on every tenant-scoped table.

withOrg() is the sole permitted path to the database — every route, job, and use-case goes through it.

PgBouncer is deployed in transaction mode, which ensures the tenant GUC resets between connection checkouts.

Document security

Invoices arrive via upload or inbound email. Every file is screened before it touches the processing pipeline.

Antivirus scanning. All uploads and email attachments are scanned via ClamAV (INSTREAM protocol) before any OCR or AI processing begins. Files that fail scanning are rejected and logged; they never enter the document queue.

PDF sanitization. PDFs are sanitized before storage — JavaScript entry points, additional actions, embedded files, and XFA forms are stripped. The sanitized file is what reviewers see and what the AI reads.

Per-org ingest rate limiting. Inbound volume per organization is capped on a rolling window, preventing a flood of documents from starving other tenants' processing queues.

Email authentication

Greenbar Pay accepts invoices via a dedicated inbound email address. To prevent spoofed invoice injection, we enforce sender authentication before processing any attachment.

SPF and DKIM are evaluated on every inbound message. An email that fails both checks is rejected before any attachment is created.

DMARC policy is honored: messages that fail DMARC under a domain's published quarantine or reject policy are also rejected.

AWS SNS message signatures are cryptographically verified before processing inbound email notifications.

Fraud and manipulation controls

AP fraud often arrives in the data itself — changed bank details, manipulated totals, or repeated invoice numbers. Greenbar Pay applies deterministic checks at every approval step.

Remit-to drift detection. If a vendor's payment address on a new invoice differs from their most recently approved invoice, reviewers see an explicit warning before approval.

Duplicate invoice detection. Invoices with matching vendor, number, and amount are flagged before they can be approved a second time.

Prompt injection hardening. The AI extraction prompt explicitly frames document text as untrusted data and names common injection patterns. Detection is versioned and logged.

PO matching. Invoices referencing a purchase order are validated against your PO register before approval. Three-way matching (with receipt confirmation) is available per organization.

Audit trail

Every approval, rejection, export, and override in Greenbar Pay is recorded in an immutable audit log. The log is designed to survive as long as the records do.

Append-only audit events — UPDATE and DELETE are blocked at the database rule level, not just the application level.

Events are partitioned by month for query performance, with a 7-year retention target.

Approved invoices are sealed in an evidence packet containing the extracted data, validation findings, and the approver's identity and timestamp.

Access control

Role-based access control with four tiers: Owner, Admin, Reviewer, and Approver. Permissions are enforced server-side on every route.

Mutating API endpoints require an Idempotency-Key header; state-changing operations take an If-Match header for optimistic concurrency control.

AI usage is rate-limited per organization per day, preventing any single tenant from exhausting shared model capacity.

Data in transit

All traffic between your browser and Greenbar Pay is encrypted via TLS.

Inbound emails are received over encrypted SMTP. Webhook notifications are verified by signature before processing.

Certifications and roadmap

We are building toward SOC 2 Type II certification. Many of the required controls — immutable audit logging, tenant isolation, incident response hooks, and least-privilege access — are already implemented. We expect to engage an auditor and begin the observation period in 2027.

If your organization requires security documentation ahead of a purchasing decision, we can provide a completed security questionnaire and schedule a security review call. Reach us at security@greenbarsystems.com.

Responsible disclosure

If you believe you have found a security issue in Greenbar Pay or greenbarsystems.com, please report it to security@greenbarsystems.com. We will acknowledge your report within two business days. Please do not publicly disclose the issue before giving us a reasonable window to address it.

Do not access, modify, or delete data that is not yours.
Do not perform denial-of-service or automated scanning without prior authorization.

Last updated: July 2026. Questions? Email security@greenbarsystems.com.

← Back to home Privacy Policy →