Privacy Policy

Vallis Last updated: 12 October 2026

Draft note: delete this block, and the two below it, before publishing.

Every factual claim here was written against the code as it stands, not against the roadmap: 2026-08-19 for the document as a whole, and 2026-09-22 for §2.7, which was rewritten when contacts import shipped. Sections marked [NOT YET TRUE] describe features that are specced but not built, and must stay out of the published policy until they ship. A policy that over-discloses is as wrong as one that under-discloses.

No paperwork items are open. Items 1, 2 and 3 are all done, and what remains before publishing is the [NOT YET TRUE] audit below plus stripping these blocks and the noindex.

One [NOT YET TRUE] block is left, and one [PARKED] block, and they are not the same kind of thing:

• §2.8 Purchases is [NOT YET TRUE] - specced, unbuilt, waiting on the RevenueCat flow. It must be published when that ships.
• §2.6 server-sent reminders is [PARKED] - a tripwire rather than an outstanding item. Reminders shipped 2026-09-22 and send from the member’s own number, so that block describes a channel the product decided against. Do not wait on it, and do not publish it.

Contacts (§2.7) came off on 2026-09-22 when the feature shipped.

1. Vallis LLC must actually exist. FORMED 2026-08-27. §1 and §12 name it as the operator and data controller, and that is now a true statement rather than an anticipated one. It was the reason this policy could not be published: naming an entity that does not exist is the one error this document cannot carry, since being wrong about who you are is worse here than in any other section.

The address in §1 and §12 is the LLC mailing address at Boardwalk Terrace, Orland Hills, Illinois (replacing the cancelled Springfield virtual office). It is also NOT the principal place of business, which appears nowhere in this repository and should stay that way: a published policy is scraped permanently, and under the EU DSA a trader’s address is republished on the App Store listing as well.

2. The PostHog DPA must be signed SIGNED 2026-08-27 (§5). It was the only one of the four that needed signing, and it needed the company name and registered address, so it was blocked behind the item above.

Verified 2026-08-19, so these do NOT need chasing:

Processor	DPA status
Supabase	Automatic. “Acceptance of the Agreement shall have the same effect as signing the SCCs.”
Extraction provider	Automatic. “Incorporated into the Agreement(s)”; no separate opt-in.
Cloudflare	Automatic on a self-serve plan. Its GDPR trust hub states the DPA “is incorporated by reference into our Self-Serve Subscription Agreement”. The DPA’s own “from the date on which Customer signed” wording is the Enterprise path, and reading it alone gives the wrong answer for a free or Pro account.
PostHog	Signed 2026-08-27. Was the only one needing manual signature.
Resend	Automatic, executed copy saved 2026-09-22. “Shall become legally binding upon Customer entering into the Agreement.” Added late: it became a processor on 2026-09-02, after this table was first checked.

3. The Resend DPA must be accepted AUTOMATIC, verified 2026-09-22 (§5). Resend became the sender on 2026-09-02, which makes it a FIFTH processor and is why §4 now has five rows, so it genuinely was not covered by the table above - that was verified in August, before Resend existed here.

It needed no acceptance. Resend’s published DPA is self-executing, the Supabase pattern rather than the PostHog one: “This Addendum shall become legally binding upon Customer entering into the Agreement”, and “execution of the Agreement by the Data Importer and the Data Exporter shall constitute execution of these Clauses by both parties”. It binds from the day the account was created.

The executed copy has been retrieved from the Resend dashboard and saved (2026-09-22). That is the difference between reading the published terms and holding the agreement: the published page says what the terms are, the retrieved copy is evidence that they apply to this account. Keep it with the signed PostHog DPA - an accountability request under GDPR Art. 28 asks for the agreement, not for a link to a vendor’s website that may have moved on.

The dashboard line is what misread as a to-do. The DPA says “The executed version of this DPA may be accessed by Customer through the Resend dashboard at any time following execution” - the dashboard is where the signed copy is RETRIEVED, not where it is accepted. That is the same class of mistake the Cloudflare row below records in the opposite direction, where the signature wording belongs to a path this account is not on.

It is named outright rather than described by category, unlike the extraction provider. The reason for that one is specific to it (see below) and does not generalise - and a table carrying two unnamed providers reads as evasion rather than as the single deliberate exception it is.

Also confirmed 2026-08-19: in-app account deletion now exists (Settings → Account → Delete account), so Apple’s half of §8 is discharged alongside Google Play’s.

The extraction provider is named nowhere in this file, deliberately (2026-08-31). §2.3 and the §4 table describe it by category. This note used to name it, which defeated the point: these draft blocks are SERVED on /privacy until they are stripped, so an internal note here is a public disclosure with extra steps.

The vendor, the billing condition that keeps §2.3’s no-training claim true, and the reasoning behind describing it by category all live in supabase/scripts/deploy-hosted.md, hazard 4, in the private repo. Read that before editing §2.3 or the §4 table.

The one thing that has to stay visible here: §5’s offer to name the provider on request is load-bearing. Category-level disclosure is permitted only alongside it. If that sentence is ever cut, §2.3 and §4 have to go back to naming the vendor.

None of this is legal advice. A US LLC collecting third-party phone numbers and serving EU users should have a lawyer read it once.

The short version

Vallis splits a restaurant or grocery bill between friends. To do that it needs your receipt and the names of the people you’re splitting with.

• We do not move money. Vallis opens Venmo, Cash App, PayPal, or your phone’s messaging app; we never see a payment, a card, or a bank account.
• We do not store your receipt photos by default. The image goes to our extraction provider, comes back as text, and is discarded. Gold members can turn on saving the photo with a split; it is off unless you turn it on, and §2.3 says exactly what happens then.
• We do not sell or share your data, and there is no advertising in Vallis.
• Our product analytics are built so they cannot carry amounts, names, or phone numbers. That’s enforced in the code, not just promised here.

1. Who we are

Vallis is operated by Vallis LLC, 16406 Boardwalk Terrace, Orland Hills, Illinois, United States.

Email support@vallis.app for questions about Vallis. Privacy requests (copies, correction, deletion) can also go to privacy@vallis.app.

Vallis LLC is the data controller for the information described below.

2. What we collect, and why

2.1 Your account

When you create an account we collect your name, email address, and a password. The password is hashed by our authentication provider; we never see or store the plaintext.

If you sign in with Apple or Google instead, we receive your name and email address from them. If you use Apple’s Hide My Email, we only ever receive the relay address Apple generates, and that is fine. Vallis works normally with it.

We use this to identify your account and to keep your splits attached to you across devices.

You can add a profile photo. It is optional. We store it so it can show on your avatar in the app and on the guest pay page, so the person paying can see who they are paying. You can change it or remove it.

2.2 Your splits

When you create a split we store: the merchant name and date, the line items and their prices, tax, tip, fees and discounts, and how you assigned items to people.

We also store the names of the people you split with, and their phone number or payment handle where you’ve entered one, so that we can build the Venmo or text-message handoff for you.

You can add a photo of someone you split with. That photo stays in your account. It is not shown on guest pages.

This is information about other people. See §6.

2.3 Receipt photos

When you scan a receipt, the image is sent from our server to a third-party text-extraction provider in the United States, which returns the printed text as structured data. Your phone never contacts that provider directly.

By default we do not keep the image. It is not written to our database or to any file storage; it passes through our server and is discarded once the extraction returns. What we retain is the extracted text you then review and edit.

If you are a Gold member you can choose to keep it. “Keep receipt photos” in Settings is off until you turn it on. While it is on, the photo of each new scan is stored with its split, in private storage that only your account can read. Turning it off again deletes the photos already saved.

A saved photo is deleted when you delete the split it belongs to, when you delete your account, or when you turn the setting off. Deleting your account removes them straight away. In the other two cases the file is removed by a cleanup that runs daily, so it can take up to a day for the file itself to go.

If your Gold membership ends, we keep your saved photos for 60 days and then delete them. This is so that resubscribing within that window gives you your receipts back rather than an empty space. You do not have to wait it out: you can delete them yourself at any time, and deleting your account removes them immediately. During those 60 days you can still view and delete your saved photos; you just cannot save new ones.

That provider processes the image as our service provider, on our instructions and for no other purpose. We use extraction providers only on a paid tier whose terms prohibit training on the content we send them. Your receipts are not used to train anyone’s models and are not read by human reviewers. The provider retains what we send only briefly, to detect policy violations and to meet its own legal obligations.

We describe this provider by category rather than by name. If you want to know who it is on the date you are reading this, ask us at privacy@vallis.app and we will tell you.

We also keep a small scan record for each extraction: a timestamp, which model ran, how long it took, how many items came back, and whether it succeeded. This is what enforces the free-tier scan limit and tells us when extraction quality degrades. It contains no receipt content.

2.4 Usage analytics

We use PostHog (US region) to understand where people get stuck. We record events like “a split was started”, “the receipt was extracted”, “a request was sent”, along with your account’s user ID.

Analytics events cannot contain money amounts, names, or phone numbers. This is a structural guarantee, not a policy one: the list of permitted events and properties is a closed type that fails our build if anything else is added, values are re-checked at runtime and dropped if they violate the rule, and the test suite fails if a new event is added without a privacy assertion. Where we need to know the size of an extraction error, we record a bucket (“off by more than $5”), never the figure.

We have also turned off the features that would have collected more than we want: automatic tap-capture is disabled permanently (it would have recorded the text of whatever you tapped, which on these screens is a dollar amount or a friend’s name), session replay is not enabled, IP addresses are discarded on arrival, and location enrichment is switched off, so we do not collect or derive your city, region, coordinates, or postal code.

Screen names are recorded as route patterns (/split/[id]/assign), never with your split’s ID in them.

If you’re in the UK or EU, see our legal bases below.

2.5 Guest pages on this website

If someone sends you a Vallis link to claim your items or report a payment, you don’t need an account and we don’t create one for you.

• The link contains a long random token. That token is the only credential, and it grants access to exactly one person’s view of exactly one split, and it cannot be modified to see anyone else’s data.
• We show you first names only. Other people’s phone numbers, email addresses and contact details are never shown on a guest page.
• The sender’s profile photo may appear, so you can see who you are paying. Photos of other people on the split are not shown.
• We record which items you claimed, or which splits you reported paying, and the time you did so. That’s what the person who sent you the link asked for.
• There is no analytics, no advertising, and no third-party tracking on guest pages. They set no cookies beyond what is needed to serve the page.
• Links expire on their own: a claim link after 14 days, a payment link after 45 days. Either can be revoked at any time by the person who sent it.

2.6 Text messages

When you send a claim link or a payment request, Vallis opens your phone’s own messaging app with the message pre-filled. You send it, from your own number. We do not transmit the message or the recipient’s number to any messaging service, and we have no record of whether you sent it.

[PARKED, NOT PENDING: server-sent reminders were parked 2026-09-20, spec 19.3b. This is a tripwire, not an outstanding item - do not wait on it and do not publish it.] Gold automatic reminders are sent from a Vallis phone number rather than yours. When that feature is enabled, the recipient’s phone number and the message body are transmitted to our SMS provider in order to deliver it, and replies to those messages are received and processed by us.

Gold reminders SHIPPED 2026-09-22 and send from the member’s own number, through the paragraph above this block rather than through the block itself. That paragraph is now the whole truth and is expected to stay it.

A DIFFERENT MARKER FROM THE ONE BELOW, on purpose. [NOT YET TRUE] means a specced feature that has not been built and whose block must be published when it is. This is the opposite case: built, deliberately built the other way, and this text describes a channel the product decided against. An audit that treats the two the same will either sit waiting for something that is never coming, or publish a disclosure for data flows that do not exist.

It is kept rather than deleted because the decision can be revisited, and if it ever is, this section is one of the things that has to change before a single message goes out.

2.7 Contacts

Vallis asks for your contacts only when you tap “Add from contacts”, and never before. If you grant permission, we read contact names and phone numbers on your device, solely to offer them for selection. We do not read email addresses, postal addresses, birthdays or any other field, and we do not upload your address book.

If you tap Use photo from contacts on a person, we read that one contact’s photograph and store it as their photo in your account. We do not read photographs for anyone else.

Only the people you tap become part of a split. Contacts you do not select are never transmitted to us and are not stored anywhere outside your phone.

Declining costs you nothing. Every person can be added by typing a name and an optional number, which is how the app worked before contacts import existed and remains the primary path.

2.8 Purchases

[NOT YET TRUE: hold until the purchase flow ships] Subscriptions are processed by Apple or Google, and managed through RevenueCat. We receive your subscription status and the transaction identifiers needed to grant access. We never receive your card or payment details.

2.9 The launch list

If you enter your email address on the front page of this website, we store that address and the date you gave it, and nothing else. No name, no IP address, no cookie, no tracking pixel.

We use it for two things and nothing else: an email telling you Vallis has launched, and occasional updates before then on how the build is going. We cap it at one message a month, we do not sell or pass your address to anyone, and we do not use it for advertising.

Every message carries a way to unsubscribe. You can also email us (§12) at any time and we will delete the entry. You don’t need an account, and you don’t need to explain why.

Signing up twice does nothing and tells you nothing: the page gives the same answer whether or not the address was already there, so it can’t be used to find out who is on the list.

2.10 Our legal bases (UK and EU)

UK and EU law requires us to name why we’re allowed to handle your information. For each thing above:

We rely on legitimate interests for analytics rather than asking for consent because of how narrowly it’s collected: no advertising identifiers, no cross-company tracking, no location, no IP address, and nothing that can identify you to anyone but us. If we ever re-enable location enrichment, that reasoning stops holding and we will ask for consent instead.

You can object to any processing based on legitimate interests. See §8.

3. What we do not do

• We do not sell your personal information, and we do not share it for cross-context behavioural advertising.
• We do not show advertising, and we do not use advertising identifiers. Vallis does not track you across other companies’ apps or websites.
• We do not process payments, hold funds, or connect to your bank.
• We do not use your receipts, splits, or usage to train our own models.

4. Who we share it with

Only the service providers that make the app work, each acting on our instructions:

We will also disclose information if we are legally required to, or to protect the rights and safety of our users.

If Vallis is ever acquired or merged, your information may transfer as part of that transaction. We’d tell you before it took effect.

5. International transfers

Vallis LLC is based in the United States and so are all of our providers, so if you use Vallis from the UK, EU, or elsewhere your information is transferred there.

Where that transfer is from the UK or EU, we rely on the Standard Contractual Clauses approved by the European Commission (and the UK Addendum), which each of the providers above includes in its data processing agreement with us.

Where the table above names a provider by category rather than by name, you can ask us who it currently is, and for a copy of the safeguards that cover it, at privacy@vallis.app.

Draft note: delete before publishing. This says we have accepted those DPAs. Supabase, PostHog, Cloudflare, Resend and the extraction provider each publish one, and most require you to actively accept it in the dashboard. Do that before publishing, or the paragraph is a claim rather than a fact. None is outstanding: Resend’s was the last open one and is self-executing (item 3 at the top).

6. Information about other people

Vallis only works if you can tell it who you’re splitting with. When you add someone’s name, phone number, or payment handle, you are giving us information about a person who is not our user.

• We use it only to build the split you asked for and the handoff link that goes with it.
• We do not use it to market to them, and we do not build a profile of them.
• If someone contacts us and asks us to remove their details, we’ll remove them from our records and tell you.
• Please only add details for people who’d expect you to, the same courtesy as putting someone’s number in a group text.

Under UK/EU data protection law you are responsible for having a proper reason to share those details with us.

7. How long we keep it

8. Your rights and choices

You can ask us to:

• Give you a copy of the personal information we hold about you.
• Correct anything that’s wrong.
• Delete your account and everything attached to it. See how to delete your account.
• Stop analytics collection for your account.
• Object to, or restrict, how we use your information.

Email privacy@vallis.app and we’ll respond within 30 days. We won’t treat you differently for exercising any of these rights.

Draft note: delete before publishing. Both deletion routes now exist: the self-serve web one at /delete-account for Google Play, and Settings → Account → Delete account in the app for Apple (Guideline 5.1.1(v)). They call the same backend, so what they delete cannot drift apart.

If you’re in the UK or EU, you also have the right to complain to your data protection authority. If you’re in California, the rights above are your CCPA/CPRA rights to know, delete, correct and opt out; we do not sell or share personal information as those terms are defined.

9. Security

Data is encrypted in transit. Access to your splits is restricted at the database level so that one account cannot read another’s. Guest links use long random tokens that cannot be guessed or enumerated, resolve to a single person’s view of a single split, expire, and can be revoked.

No system is perfectly secure, and we won’t pretend otherwise. Treat a Vallis link like a key: anyone who has it can see that one page.

10. Children

Vallis is not directed at children under 13, and we don’t knowingly collect information from them. If you believe a child has created an account, contact us and we’ll delete it.

11. Changes

We’ll update this page when the app changes, and update the date at the top. Material changes will be announced in the app before they take effect.

12. Contact

support@vallis.app

Privacy requests: privacy@vallis.app

Vallis LLC 16406 Boardwalk Terrace Orland Hills, Illinois United States