Compliance note

Purpose of this page

This compliance note summarises how Billora approaches security, key subprocessors, and data protection at a high level. It is provided for transparency and planning. It is not legal advice and does not replace your own legal, tax, or regulatory assessment. Customers with formal vendor diligence requirements should request documentation from hello@billora.com and consult qualified counsel.

What Billora does

Billora is a multi-tenant software service that stores organisation data in logically separated workspaces, connects to your email provider (via Nylas) when you authorise it, stores attachments in Amazon S3, and may use AWS Textract to extract structured fields from invoice images or PDFs. Authentication uses industry-standard practices; optional multi-factor authentication may be available. Certain user and administrator actions can be recorded in an application audit log to support accountability.

Subprocessors (summary)

Depending on features you enable and how Billora is deployed, personal data may be processed by:

• Nylas — OAuth and mailbox connectivity for supported email providers.
• Amazon Web Services — S3 object storage; Textract and related APIs for document analysis in the configured region.
• Paddle — payments, subscriptions, and related tax or compliance for checkout.
• Email delivery provider — transactional email (for example Resend, when configured via Django Anymail).
• Application hosting — runtime and managed database for the Billora application (for example the cloud or platform you or we use for production).

Each vendor publishes its own terms, certifications, and data processing addenda. A current list and further detail can be provided on request for enterprise procurement.

Data locations

Primary application data resides in the database region tied to your deployment. Files are stored in the AWS region configured for the S3 bucket. Email-related processing may involve regions described in Nylas’s documentation. Customers with strict data residency requirements should discuss architecture and configuration with us before processing regulated data.

Security practices (overview)

• Encryption in transit for browser and API traffic (HTTPS).
• Access controls and tenant-scoped queries in the application layer.
• Secrets and credentials managed via environment configuration (not committed to source control).
• Webhook and provider integrations verified where supported (for example signature checks).
• Operational monitoring, backups, and incident response proportionate to a growing SaaS product.

We do not publicly guarantee uninterrupted service or specific certification timelines. SOC 2, ISO, or pen-test summaries may be available under NDA for qualified buyers.

Regulated data and industry rules

Billora is designed as a business tool for invoice operations, not as a certified legal or accounting opinion engine. You are responsible for classifying your data (for example health, financial, or sector-specific rules) and for using the Service in compliance with laws that apply to you. We do not represent that the Service meets HIPAA, PCI-DSS as a card environment, or other sector-specific frameworks unless expressly agreed in writing.

AI and automated processing

Features such as document extraction use automated services (including AWS Textract) to suggest field values. Output may be imperfect. Human review is advised before payments, accruals, or statutory filings. We may refine models and processing pipelines over time while continuing to process Customer Data only as described in our Privacy Policy and any data processing agreement.

Privacy rights and data processing agreements

Individuals wishing to exercise privacy rights should follow the process in our Privacy Policy. Organisations acting as controllers may request a Data Processing Agreement (DPA) or vendor questionnaire by emailing hello@billora.com.

Reporting security issues

If you believe you have found a security vulnerability in Billora, please report it responsibly to hello@billora.com with enough detail to reproduce the issue. Do not perform testing that could harm other customers’ data or service availability.