weBiller Privacy Policy

Who is responsible for what

Two kinds of data pass through weBiller, and the law treats them differently. Your account (your email address, your password hash, your business profile, your settings) is ours to answer for. In GDPR terms we are the controller.

Everything you enter about the people you bill is yours to answer for. You decide who goes in the client list and why; we store it and act on your instructions, and we never use it for anything of our own. There we are the processor and you are the controller.

If your own obligations need a signed data-processing agreement, write to webiller1@gmail.com and we will put one in place.

What weBiller collects

Nothing is collected sideways. Every item below is either something you entered or something the app cannot run without.

• Account data: your email address, an optional name and avatar, a bcrypt hash of your password (never the password itself), your language and theme preferences, and the sessions you have open.
• Sign in with Google or Apple: if you use one, we store the identifier that provider uses for you, the email address it told us, whether it said that address was verified, and when the link was made and last used. We never see your Google or Apple password, and we ask for nothing beyond your name and email. If you use Apple’s Hide My Email, we only ever hold the forwarding address, not your real one.
• Business data: business name, address, VAT and registration numbers, logo, bank details and invoice numbering. The things that have to appear on an invoice.
• Client data: whatever you enter about the people you bill: name, company, email, phone, postal address, VAT number, currency, payment terms, and your own notes.
• Documents: invoices, quotes, credit notes, subscriptions, payments, expenses and time entries, with their line items and their history.
• Files: logos, avatars, receipts and anything else you attach, plus the PDFs generated from your documents.
• Device tokens: if you turn on push notifications in the mobile app, the notification token for that device and the platform it runs on.
• Technical data: the ordinary request logs our hosting providers keep: IP address, timestamp and which endpoint was called, for security and debugging.
• Security log: for account-security events specifically (signing in, a failed sign-in, signing in with Google or Apple, linking one of those to an existing account, requesting or completing a password reset, changing your password, verifying your email, deleting your account) we record the event, the time, the IP address it came from and the browser or app that sent it. We keep these 90 days and use them to spot account takeovers, credential-stuffing runs and abuse of the password-reset form. A failed sign-in is logged even when the email matches no account. A sweep of made-up addresses is exactly the pattern this is meant to catch.
• Sessions: each session you have open records the IP address and the browser or app it was created from, plus when you signed in and when it was last used. You can see the list on the Account page and end any session you do not recognise.
• Quote signatures: when a client signs a quote through a link you sent them, we record the name they signed under, the signature itself, the time, and the IP address it came from. Without those a signature proves nothing, which is the point of asking for one.

What weBiller does not collect

Worth stating plainly, because several of these are the default elsewhere.

• No card numbers. weBiller does not process payments (it records that a payment happened), so there is no payment provider in the stack and no card data to store. The bank details on your invoices are the ones you chose to print there.
• No advertising trackers. No ad networks, no pixels, no advertising ID, and no third-party script watching you read this page. The website has no analytics at all. The mobile app can send usage and crash reports, but only if you switch them on — there is a section on that below.
• No sale or sharing of your data. Not to advertisers, not to data brokers, not to anyone.
• No profiling, and no automated decision-making that has a legal effect on anybody.
• No special-category data. weBiller is not built to hold health, biometric or similar data, so please keep it out of the client notes.

Why we hold it

To run the account you asked us to run: rendering your documents, delivering them, tracking what has been paid, and letting you sign in from more than one device. That is performance of a contract.

To keep the service working and safe: fixing bugs, investigating abuse, and sending the emails an account needs: verification, password resets, and notice of changes. That is our legitimate interest, and yours.

The security log and the IP addresses on your sessions sit under that same legitimate interest, narrowly: detecting and investigating unauthorised access, and rate-limiting the sign-in and password-reset forms so neither can be hammered. They are not used to profile you, to measure your usage, or for anything a marketing team would ask for. If you want to object to that processing, write to us and we will tell you what we can switch off while still running an account safely.

Our own staff can read that material. Investigating a takeover attempt or answering a support question means someone here can see your account metadata, the sessions open on your account with their IP addresses, and your security log, and can end a session on your behalf. They cannot read the contents of your invoices, your quotes, your client notes or your attachments; the internal tools do not return those fields at all. Every one of those lookups is itself recorded against the person who made it, and that record is kept longer than the 90-day security log precisely so it can be audited.

The mobile app’s usage and crash reports rest on your consent, not on any legitimate interest of ours: nothing is collected until you say yes, and one switch in Settings withdraws it with immediate effect.

weBiller sends no marketing email. Every message it sends is either a step you started (verify your address, reset your password) or a document you or your client acted on (an invoice, a reminder, a receipt).

Contacts on your phone

The mobile app can read your device address book, and for exactly one purpose: filling in the new-client form. Android asks for the contacts permission when you tap the import button; iOS asks in its own way. Decline and the rest of the app behaves identically.

When you pick someone, the app copies that one person’s name, company, email, phone and postal address into the form, on your device. Nothing leaves the phone until you save the client, and then only the fields you kept. Your address book is never uploaded, never read in the background, and never stored anywhere but your phone.

Usage and crash reports in the mobile app

The mobile app can send us two things, and it asks first. One is a note of which screens you opened and which actions you took. The other is a report when the app crashes. The first time you open the app it asks whether that is alright; whichever you answer, the switch is in Settings and you can move it whenever you like. Say no and the app behaves identically — nothing is collected, and nothing is quietly saved up to send later.

A usage report carries the name of a screen ("InvoiceDetail"), the name of an action ("invoice_sent"), your plan, your role in the business, your language and your theme. A crash report carries the error, where in the code it happened, the device model and the Android version. Both carry your weBiller user ID and a random identifier for that installation, so that a crash you write to us about can actually be found.

Neither one carries the contents of your invoices, quotes or expenses, anything at all about your clients, your files, your name, your email address, your business name, or any amount of money. That is not a promise about how carefully we filter afterwards: the app can only send event names and parameters from a fixed list written into the code, and anything not on that list is dropped on the phone before a request is ever made. There is no field for a monetary amount on that list at all.

This runs on Google Firebase — Analytics and Crashlytics. It is there so that "the app crashes when I open a quote" is something we can see for ourselves rather than something you have to describe to us. Because it rests on your consent rather than on any interest of ours, switching it off in Settings is enough; you do not have to ask us for anything or wait for us to act.

None of this exists on the website. There is no analytics on the web app, on these pages, or in the client portal your customers see.

Every other company that can touch it

weBiller runs on other people’s infrastructure. This is the complete list of sub-processors and what each one does.

• Neon: the PostgreSQL database. Everything except files lives here.
• Vercel: hosting for the web app and the API.
• Resend, for outbound email: verification, password resets, the invoices and quotes you send by email, payment reminders and receipts.
• Cloudinary, for file storage: logos, avatars, attachments and generated PDFs.
• Google, via Firebase Cloud Messaging: delivering push notifications to the device tokens described above.
• Google, via Firebase Analytics and Crashlytics: the usage and crash reports from the mobile app, for the people who switched them on. Nothing reaches them from anyone who did not.
• No one else. There is no CRM, no ad network and no support tool holding a copy of your data.

Client portal links

When you send a document to someone who has no weBiller account, weBiller mints a signed link to a read-only page for that one document. The link carries a 256-bit random token and only its hash is stored, so nobody at weBiller can reconstruct a link from the database.

The practical consequence matters more than the cryptography: whoever holds the link can read that document and report a payment against it. Treat a portal link the way you would treat the invoice PDF. Links expire after 30 days, minting a new one revokes the old one, and you can revoke a link yourself at any time from the document it belongs to.

Cookies, and what the browser keeps

weBiller sets no cookies for advertising or analytics, and the website has no analytics of any kind.

The mobile app keeps the same four things described below on your phone, plus your answer to the usage-reports question. The web app keeps these four in your browser’s local storage, all of them needed to work:

• your access and refresh tokens, so you stay signed in
• your theme choice, so the page does not flash the wrong colours on load
• your interface language, for the same reason
• a cache of data the app has already fetched, so screens you have visited open instantly

How long it is kept

Account, business, client and document data stay for as long as your account exists. weBiller does not expire or archive your invoices on its own.

You can delete your account yourself, from the Account page, by confirming your password. That removes the account and everything hanging off it (businesses, clients, invoices, quotes, payments, attachments, notifications and sessions) immediately, with no grace period and no undo. Export first.

The security log described above is kept 90 days and then deleted, by a job that runs daily rather than by anyone remembering to do it. Delete your account and its security log goes with it in the same sweep as everything else; the only rows that outlive that are failed sign-ins against addresses that never had an account, which have nothing to attach to and roll off on the same 90-day clock. Records of what our own staff did to an account are kept longer: that trail exists to hold us accountable, so it is not on the 90-day clock.

Sessions are deleted when you sign out or when they expire, kept a further week so a sign-in you did not recognise is still there to look at.

Spent verification and password-reset tokens are deleted daily by the same job. Deleted rows can survive a short while longer in our database provider’s routine backups before those roll off. Verification, password-reset and portal tokens are stored only as hashes and expire on their own. Request logs roll off on our hosting providers’ schedules rather than ours.

Getting your data out

Before you delete anything, take it with you. Every invoice downloads as a PDF and as UBL 2.1 XML, which is the format accounting software imports without retyping.

From Settings you can also export invoices, clients and payments as CSV, and pull a full account export: one JSON file with your business profile, settings, clients, catalog items, invoices with their line items and payments, quotes, expenses and subscriptions, plus your open sessions, your security log and any Google or Apple account linked to yours.

Your rights

If the GDPR applies to you, you have the right to see the data we hold about you, correct it, delete it, take it elsewhere in a portable format, restrict or object to how we use it, and withdraw any consent you gave.

Most of that you can do faster than we could: the app already lets you read, edit, export and delete everything in it. For anything the app cannot do, or if you would rather we did it, email webiller1@gmail.com. We will answer within 30 days.

If we hold data about you because one of our users invoiced you, they are the controller and we are only the processor. Ask them first, and if they come to us, we will help them answer.

If you think we have handled your data badly, you can complain to the data protection authority in the country you live in. We would rather you told us first, but that is your call, not ours.

Where the data lives

The database is hosted by Neon and files sit with Cloudinary. Email goes out through Resend and push through Google. Several of those are United States companies, so some of your data is processed outside the European Economic Area.

Those transfers run on the data-processing terms each of those providers publishes, which is where their standard contractual clauses are set out. We have not built anything custom on top of them, and we are not going to pretend otherwise.

Security, and what we are not claiming

Passwords are stored as bcrypt hashes, never in plain text, and we cannot read yours. Sessions use a short-lived access token plus a refresh token that is stored hashed and can be revoked; changing your password revokes every session on the account. Portal, reset and verification tokens are random, stored as hashes, and expire. Everything travels over HTTPS.

What we are not claiming: weBiller holds no ISO 27001 certificate, no SOC 2 report and no third-party penetration test. It is a young product built carefully, which is not the same thing as an audited one, and you should not read it as such.

Children

weBiller is a tool for running a business and is not directed at children. You need to be old enough to enter into a contract to hold an account. See the Terms. If you believe a child has signed up, email us and we will delete the account.

Changes to this page

When this policy changes, the date at the top changes with it. Anything material gets an email to account holders rather than a quiet edit at two in the morning.

Contact

Privacy questions, data requests, anything legal, or a correction to something written here: webiller1@gmail.com.

weBiller is operated by weBiller.