Privacy Policy
Last Updated: October 2026
This Privacy Policy explains how Floe Labs, Inc. (“Floe,” “we,” “us”) collects, uses, discloses, and protects personal information in connection with the reconciliation service described in our Terms of Use (the “Services”), the application at, and the website at https://floefinance.com. It is written for the people who sign in to the Services on behalf of a customer, and for the customers whose files the Services process.
The Services recount a vendor invoice against a buyer’s own records. That work necessarily involves files that contain personal information about the buyer’s customers and staff. Much of this Policy is about how little of that information leaves the file it arrived in, and how long the file itself is kept.
1. Scope and Roles
Floe acts in two different capacities.
Floe as controller. For information about the people who use the Services (account holders, invited workspace members, and the representatives of buyers and sellers who correspond with us), Floe is the controller, or “business” under U.S. state law. Sections 2 to 10 apply to that information.
Floe as processor. For personal information contained in the files a buyer uploads or the systems a buyer connects (helpdesk conversation exports, vendor billing exports, invoices, order forms, refund feeds, rules sheets, and the countersigned Definition), the buyer is the controller and Floe is the buyer’s processor or “service provider.” Floe processes that information only to perform the Services for that buyer under the Terms of Use and any data processing agreement between us. The buyer is responsible for giving notice to and, where needed, obtaining consent from its customers and staff. If you are a customer or employee of one of our buyers and have a question about your information, please contact that company; we will support it in responding. Section 11 describes what we do with this information.
2. Information We Collect as Controller
Category | Examples | Source |
|---|---|---|
Account and workspace data | Name, work email, company, workspace role, the identifiers our sign-in provider assigns to your user and your organization. | You, your workspace administrator, our sign-in provider (Clerk). |
Activity in the Services | Which engagements you created, which files you uploaded and when, when a report was delivered, which operator ran or reviewed a step, and every time a signed-in user read a buyer’s files (the access log). | Generated by the Services. |
Countersignatures | A countersigned Cleared Work Definition is a PDF that carries the signers’ names and signatures. We store the company names of the parties and the hash of the PDF; the PDF itself is a raw upload and follows the deletion rule in Section 6. No signer’s name is stored outside the PDF. | The buyer and the seller. |
Technical data | Session cookies set by our sign-in provider, browser and device type, and, in error reports, the route and request identifier involved. We do not record your IP address in error reports. | Your browser; our sign-in and hosting providers. |
Communications | Emails and other messages you exchange with us, including about an engagement, a walkthrough, or an exception. | You. |
We do not collect special categories of information about account holders, and we ask that you not include any in messages to us.
3. How We Use Information We Hold as Controller
To create and secure your account and workspace, and to scope what you can see to your company.
To run, review, deliver, and reproduce engagements, and to keep the access log that shows a buyer who read its data.
To respond to questions and exceptions, hold walkthroughs, and send the service emails each step of an engagement requires. We do not send marketing email to the application’s sign-in addresses without a separate opt-in.
To detect and investigate errors, abuse, and security incidents.
To comply with legal, tax, and recordkeeping obligations, and to establish or defend legal claims.
Where the GDPR or UK GDPR applies, we rely on performance of a contract, compliance with a legal obligation, and our legitimate interests in operating and securing the Services. We do not make decisions about account holders by solely automated means that have legal or similarly significant effects on them.
4. Cookies
The application sets only the cookies our sign-in provider needs to keep you signed in and to protect your session. The application does not use advertising cookies, third-party analytics scripts, or session recording. The public website may use first-party cookies to remember preferences and measure traffic; you can control those through your browser. We do not sell personal information and do not share it for cross-context behavioral advertising, so there is no “sale” or “share” to opt out of under U.S. state privacy laws. We honor Global Privacy Control signals where they apply.
5. How We Share Information
We share personal information only as follows.
Service providers (subprocessors). The Services run on providers that process information on our instructions under contractual confidentiality and data-protection terms:
Provider | What it does for us | Where |
|---|---|---|
Clerk | Sign-in, sessions, users and organizations. | United States |
Vercel | Hosts the web application. | United States (Washington, D.C. region) |
Google Cloud | Object storage for uploaded files and outputs, the database, key management (sealing credentials and per-engagement hashing keys), the engine that runs each audit, and an analytics warehouse. | United States (Northern Virginia region) |
Sentry | Error reporting. Receives the error type, a redacted message, a stack trace, the route and request identifier, and the release. It does not receive request bodies, cookies, query strings, IP addresses, or user identifiers, and we have disabled tracing, profiling, and session replay. Emails, phone numbers, and long quoted values are removed from messages before sending. | United States |
A timestamp authority | Issues the independent time stamp on each sealed evidence manifest. It receives a hash only. | Varies |
Your helpdesk provider. If a buyer connects a read-only access token instead of uploading an export, Floe calls the buyer’s helpdesk API (for Fin, Intercom’s API) with that token when the buyer starts a pull. Floe is then a client of a system the buyer already uses; the helpdesk provider is not Floe’s subprocessor.
Between a buyer and a seller. Where both have countersigned a Cleared Work Definition, the seller sees the Cleared Work Statement, the methodology page, and the exception threads for that account. Those contain record identifiers (such as conversation ids), outcome lines, rule references, and reasons. They never contain message content, contact identifiers (hashed or not), the buyer’s rules sheet, the buyer’s export, or the buyer-only outputs. The buyer decides whether and when to send the vendor-facing files to its seller; Floe does not send them.
Professional advisors, such as lawyers, accountants, and insurers, under confidentiality.
Authorities and legal process, where we believe disclosure is required by law or necessary to protect rights, safety, or the integrity of the Services. We will notify the affected customer where the law allows.
A successor in a merger, acquisition, financing, or sale of assets, on the same terms as this Policy.
We do not sell personal information, and we do not disclose it to data brokers or advertising networks.
6. Retention
Our retention rules are fixed by the design of the Services and are the same for every customer.
Raw uploaded files: deleted thirty days after report delivery. Every version of every file a buyer uploaded for an engagement (conversation export, vendor export, invoice, order form, refund feed, outcome report, countersigned Definition, and the snapshot of the access log the run read) is deleted thirty days after the report is delivered. Exception notes filed by either party on that engagement are deleted at the same time. These files are the only place in the Services where message content and unhashed contact identifiers exist. A retention job performs the deletion, confirms that the storage bucket’s soft-delete recovery was off so nothing remains recoverable, and writes a deletion certificate recording what was deleted, by file hash and object version. A verification step then checks that no raw file remains. The certificate itself is kept.
Derived records: kept. We keep the records the Services derive from the raw files: the ledger of matched and classified billed units, the run outputs (report, dispute files, renewal levers, and the per-row classification detail), the sealed evidence manifests, the per-engagement hashing key, the analytics copies described in Section 11, and any sealed access token until the buyer revokes it. We keep them so that a past engagement can be re-audited or verified, so that the manifest continues to prove what was audited, and for benchmarks, trends, and improving our rules and matching logic. Contact identifiers in these records are pseudonymous (Section 11). Record identifiers such as conversation ids remain in them.
Account data is kept for as long as your workspace is active and for a reasonable period afterwards to meet legal and audit obligations. Workspace membership can be removed by your administrator at any time.
Error reports are kept by Sentry for the retention period of our plan, not by Floe.
Communications are kept for as long as needed to handle the matter and for legal and audit purposes.
7. Security
Uploads go directly from the buyer’s browser to private storage over a short-lived signed link and do not pass through email. The browser computes each file’s SHA-256 fingerprint before upload and the Services re-check it against the stored bytes on every read. Helpdesk access tokens and per-engagement hashing keys are sealed with a cloud key-management service and are never displayed after receipt. Database rows are append-only; corrections are new revisions, never updates, and a dedicated deletion role can delete raw files and exception notes only. Access from our hosting to our cloud project is keyless, using short-lived federated identities. Every read of a buyer’s files by a signed-in user or by the engine is logged, and the buyer receives that log with its report. Our staff access production data only to run, review, or reproduce an engagement, or to investigate an incident. No system is perfectly secure, and we cannot guarantee that unauthorized access will never occur; if it does, we will notify affected customers as the law and our agreements require.
8. International Transfers
Floe is based in the United States and processes information there. If you access the Services from the European Economic Area, the United Kingdom, or Switzerland, your information will be transferred to the United States. Where we act as processor for a buyer in those regions, we rely on the European Commission’s Standard Contractual Clauses, with the UK Addendum where relevant, under our data processing agreement with that buyer. Where we act as controller, we rely on the same clauses with our providers or on another lawful transfer mechanism.
9. Your Rights
Depending on where you live, you may have the right to access, correct, delete, or receive a copy of the personal information we hold about you as controller, to object to or restrict certain processing, and to lodge a complaint with a supervisory authority. To exercise these rights, write to hello@floefinance.com. We will verify your request, respond within the time the law requires, and will not treat you differently for making it. You may use an authorized agent where the law permits.
Two limits follow from how the Services work. First, if your request concerns information contained in a buyer’s files, we will refer you to that buyer, which is the controller, and act on its instructions. Second, the derived records we keep contain contact identifiers only in hashed form under a key specific to each engagement. We cannot look up a person in those records by name, email, or phone number, and we cannot reverse a hash into the identifier it came from, so we cannot act on requests to locate or delete an individual within them after the raw files have been deleted.
California and other U.S. state residents. You have the rights described above, including to know the categories of information we collect and disclose. We do not sell or share personal information, and we do not use or disclose sensitive personal information for purposes that would give rise to a right to limit.
10. Children
The Services are for businesses, and account holders must be adults acting for their employer. We do not knowingly collect personal information from anyone under 18. The files a buyer uploads may concern customers of any age; that information is processed only for the buyer and only as Section 11 describes.
11. Information We Process for Buyers
This section is addressed to buyers, and through them to their customers and staff. It describes, field by field, what happens to the personal information in the files a buyer uploads. A fuller inventory is available on request.
What the files contain. A helpdesk conversation export contains message bodies and the identifiers of the people in the conversation: customer emails, phone numbers, and user ids, and the ids of the buyer’s support staff. A vendor billing export contains conversation ids and outcome types. An invoice and an order form contain the buyer’s and vendor’s commercial details. A refund feed contains customer emails, refund times, amounts, and currencies. A rules sheet contains the emails or domains of the buyer’s own staff, test, and automation accounts.
What the Services read. The engine reads message metadata: who wrote each part, when, in what state the conversation was, and whether the customer saw it. It reads conversation ids, timestamps, outcome types, quantities, and rates. From a refund feed it reads the email, the time, the amount, and the currency, and ignores every other column. From a helpdesk outcome report it reads the conversation id and the resolution state, and no other column.
What is never copied out of the raw file. Message content. It is read in place to compute metadata and is never written to the database, any output, any log, any error report, or any analytics table. The same is true of any column the engine does not read.
Hashing at ingest. Every contact identifier (email, phone number, user id) is replaced, at the moment it is read, by an HMAC-SHA-256 under a key that belongs to that engagement alone and is sealed in our key-management service. The hashed value lets the engine tell that two conversations involve the same customer; it cannot be reversed without the key, and the same person hashes to a different value in a different engagement.
What the outputs contain. The report, the dispute files, the renewal levers, the classification detail, and the Cleared Work Statement contain conversation ids, outcome lines, rules, reasons, and amounts. The report also contains the access log, which names, by user id, the signed-in users who read the buyer’s files. No output contains a message body or a contact identifier.
Analytics. After each audit the engine loads one row per classified unit and one row per run into an analytics warehouse that spans all buyers. Those rows carry the buyer’s organization id, the engagement id, conversation ids, outcome types, rule results, and amounts. They carry no contact identifiers, not even hashed ones, and no message content. We use them to understand how rules perform across vendors and to improve matching, classification, and the rulesets we apply, as the Terms of Use describe.
Deletion. Raw files are deleted thirty days after report delivery as Section 6 describes. The buyer may also revoke a connected access token at any time in its helpdesk; Floe does not use a token except when the buyer starts a pull.
12. Changes to This Policy
We may update this Policy. Changes will be shown by a new “Last Updated” date, and material changes will also be notified to workspace administrators. Because the retention and processing rules in Sections 6 and 11 are built into the Services, a change to them will be described explicitly rather than by a general notice.
13. Contact
Floe Labs, Inc. Delaware, USA · Privacy requests and questions: hello@floefinance.com
If you are in the EEA or UK and we are required to appoint a representative or a data protection officer, their contact details will be given here.