Privacy Policy

This policy explains what LMNTL, LLC ("we," "our," or "us") does with personal information across all of our products.

It is one policy for every brand. TimerDB, Hour Timesheet and Minute7 are products of the same company, run on the same systems, by the same people, under the same commitments. We used to publish a different policy for each, and they drifted apart — which meant the answer to "what do you do with my data?" depended on which page you happened to land on. There is now one answer. Every brand's privacy link resolves here, and an automated check verifies daily that they all deliver an identical document.

1. Two roles, and which one applies changes the answer

Almost every question about our handling of personal information has a different answer depending on whose information it is. Most policies bury this. We lead with it, because it decides everything below.

We are the controller for information about you as a visitor or an account-holder: what you do on our marketing sites, the account you create, the emails we send you about the service, and the support conversations we have. We decide why we hold it, and this policy governs it.

We are the processor for the information our customers put into the product — their employees' timesheets, expenses, payroll figures, charge codes and calendar-derived entries. That data belongs to the customer, who is its controller. We handle it on their documented instructions, under our agreement with them.

If you are an employee whose employer uses one of our products:

• Your employer, not us, decides what is recorded about your work, who can see it, and how long it is kept in their account.
• Questions about why something about your work is recorded should go to them.
• We will still help you exercise your rights — but for most requests we must refer you to your employer, and we will tell you so promptly rather than leaving you waiting.

Where a section below applies to only one of these roles, it says so.

2. Connecting a calendar

This section is near the top, and it is specific, on purpose. Connecting a work calendar means granting access to a record of who you met and when — so you should be able to read exactly what we do with it without hunting through a legal document.

Connecting a calendar is optional, per-person, and off until you turn it on. Your employer cannot connect your calendar for you. Nobody else in your company can. The consent is yours and it is revocable.

2.1 What we ask for

Every one of these is read-only: no scope we request permits us to create, change or delete anything in your calendar, and none of them lets us read your email, your files, your contacts, or anyone else's calendar. For Google, calendar.events.readonly is the narrowest scope that reads events at all. For Microsoft we do not claim that: Calendars.ReadBasic is narrower still, and whether it returns everything this feature needs is a question we are evaluating rather than one we have answered. These exact scope strings are pinned by an automated test in our codebase, so widening them is not something that can happen quietly in a release.

2.2 What we read, and what we keep

We read the events in the date window you are working on: subject, start and end time, organiser, whether you accepted, and whether the event is marked private, free or all-day.

What we store is narrower than what we read. For each meeting that becomes a proposed time entry:

• the meeting subject
• the organiser's email address
• start and end time
• identifiers that let us recognise the same meeting again, so re-syncing never double-charges you
• how a charge code was chosen for it, and what matched

What we never store:

• Event bodies. Meeting descriptions, agendas, notes and attachments are not read into our records at all.
• Attendee lists. There is no attendee field on the record we keep. We read who was invited in order to work out the right charge code, but the list itself is never written down.
• Anything from an event you marked private or confidential. By default private, confidential, declined, all-day and free-marked events are excluded before anything is stored, and a company can only make those rules stricter, never looser, for private events.

Two honest caveats on the list above, because a promise with an unstated exception is worse than a narrower promise. Outlook's separate "Personal" label is not treated as private — it sits next to Private in the same menu, but only Private and Confidential are excluded, so mark a meeting Private if you do not want us to read it. And while we never store the attendee list, a single attendee address is saved in one case: if you or your administrator create a rule that matches a specific person, we record which address the rule matched on that meeting, so the reason for the charge code can be shown to you and to an auditor. A rule the product learns from you keeps that address too, for as long as you keep the rule — section 2.8 says what it holds and how to delete it.

2.3 Nothing reaches a timesheet without a person

A connected calendar produces drafts. Every proposed entry is shown to you, with the charge code we suggest and why we suggested it, and none of it becomes a time entry until you confirm it. We do not book hours on your behalf. If a meeting you already billed later moves or is cancelled, we flag it for you in your review queue the next time that calendar syncs — we do not silently change hours that are already on your timesheet.

What happens at the moment you confirm depends on one of your employer's settings. Normally the entry is created as a draft and you submit it yourself later. If your employer has turned on submit on create, confirming also submits that entry — and submitting a timesheet entry is your certification of it, so it is worth knowing which way yours is configured. Approval is never automatic either way: no confirmation of yours approves anything, and nobody is recorded as having approved hours they did not approve.

2.4 How long we keep it

Calendar-derived records are deleted after 90 days by default. That window is configurable per customer — shorter, or longer up to a maximum of two years — though today changing it is something your employer arranges with us rather than a switch in the product, so unless they have asked us for a different figure, yours is 90 days. The deletion runs whether or not the calendar feature is switched on for them, so turning the feature off is never a way to keep this data indefinitely.

Where a meeting has already become a time entry, the entry itself is your employer's business record and stays. When the underlying calendar record is deleted, or when you disconnect, we redact our copy of the meeting content — the subject and the organiser are removed from the calendar record — while keeping the minimum needed to show an auditor how that charge was arrived at: which entry, which charge code, which method, and when.

One thing that redaction does not reach, and you should know it. When you confirm a meeting, its title becomes the description of your time entry. That description is part of your timesheet — your employer's business record — so neither disconnecting nor the deletion window above removes it. If you would rather it did not say what the meeting was called, edit the description on the time entry itself; it is yours to change.

The window does not reach a second thing either, for a different reason. A rule the product learned from you and you accepted is your configuration, not a calendar record, so it is not swept on a timer — it is kept until you delete it, and section 2.8 is about exactly that.

2.5 Disconnecting, and the two times we do it for you

You can disconnect a calendar yourself, at any time, from the calendar page. When you do, in this order, we:

1. stop our subscription to change notifications from the provider;
2. ask the provider to revoke our access, where the provider offers a way to do that. Google does, and normally honours it — but this step is best-effort: if Google is unreachable or refuses, we log it and continue disconnecting rather than trapping you in a connection you asked to end. Microsoft exposes no endpoint we can call with the scopes we hold, so there the grant always remains until you remove it. For both providers you can check and remove our access yourself in your Google or Microsoft account settings, and for Microsoft the product tells you so when you disconnect;
3. delete the calendar-derived records that have not become time entries, and redact those that have;
4. discard the stored access and refresh tokens; and
5. remove the connection.

Step 3 is not best-effort. If it fails, the disconnect fails and stays visible so you can retry — rather than reporting success and leaving your data behind.

You can also revoke our access directly with the provider at any time without telling us. If you do, the connection stops working and the product tells you to reconnect; it does not silently keep trying. Our copy of the credential goes with it: the first time we try to use it and the provider refuses, we discard the stored access and refresh tokens in the same step that marks the connection as needing reconnection. We would rather state that precisely than round it up — the erasure happens when we next try, because being told no is how we find out. What revoking does not do is remove the meeting data the connection already produced. For that, disconnect, which runs the five steps above.

Two things run that same disconnect for you, without your having to ask. If your employer cancels their account, we run it for every calendar connected in that company — because once an account is cancelled its people can no longer sign in, so nobody is left who could press the button, and the alternative is us sitting on live keys to an ex-customer's calendars. And if their account is deleted outright rather than closed, we run it before the deletion rather than after — so the access is handed back, instead of the only record that we have it being destroyed along with everything else.

Both use the five steps above unchanged, with the same best-effort revoke described there: with Google the grant is normally revoked, with Microsoft it stays until you remove it in your Microsoft account. One difference is worth stating rather than leaving you to find out. When you disconnect, a failed erasure fails loudly so you can retry; in these two there is nobody to retry, so a connection that will not come apart is recorded and the rest still proceed rather than the whole thing stalling. And reinstating a cancelled account does not reconnect anyone's calendar — everybody connects again from scratch, which is the position you would be in if you had revoked our access at the provider yourself.

2.6 Google API Services User Data Policy

Our use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically, data obtained through Google Calendar APIs is:

1. used only to provide and improve the calendar-derived timekeeping features described in this section — turning your meetings into draft time entries you review;
2. not transferred to others except as necessary to provide those features, to comply with applicable law, or as part of a merger or acquisition with notice to affected users;
3. not used for advertising, and not sold; and
4. not read by any human, except with your explicit consent for a support request you raised, for security purposes, or where the law requires it.

The same commitments apply to data we obtain through Microsoft Graph. We do not treat one provider's users as better protected than the other's.

2.7 Automated suggestion of charge codes

The product can suggest a charge code for a meeting. It does this in a fixed order, and every step except the last runs entirely inside our own systems: a tag you typed into the meeting subject, a rule your administrator set up, a rule you accepted before, or the code the meeting's organiser already used.

The last step uses a large language model, and it is switched off across the entire platform. It is a separate setting from the calendar feature itself, deliberately, so that turning calendars on does not start sending meeting subjects to a third party. It is also a setting we control platform-wide, not one your company can turn on — so while it is off, it is off for everyone, and no customer can be opted in individually.

If we do enable it, the model provider is Anthropic, and what it would receive is the meeting subject and the attendees' email domains — @acme.com, never alice@acme.com. Never meeting bodies, never full addresses. The reduction to domains happens before the request leaves our systems, not at the far end. Anthropic operates under terms that do not permit training on the data. At the time of publication this capability is not enabled for anyone. If that changes, this section changes with it, and a test in our codebase fails until it does. Every suggestion a model makes is labelled as a model suggestion in the review screen, so you always know which suggestions came from where.

To be unambiguous, because "not enabled for anyone" is easy to read too broadly: that sentence is about this capability — suggesting a charge code from a meeting — and not about models generally. There is one other place a model is involved: reading a receipt you submit for reading, in section 3.4. It uses the same provider, it is a different setting, and unlike this one it is available — off by default, and only for the companies that switch it on.

2.8 The rules your calendar teaches your timesheet

One of those steps was "a rule you accepted before", and it is worth its own section, because it is the one piece of what your calendar tells us that is designed to outlast the calendar connection. When you make the same decision three times — charging meetings a particular person organises to the same code, or keeping the same recurring block out of your queue — the product proposes remembering it. It never turns a rule on by itself: a rule in force is one you pressed accept on.

What a rule remembers is personal information. For a "charge these to this code" rule it is the organiser's email address; for a "keep these out of my queue" rule it is the meeting's subject or the identifier of the recurring series. We keep that value from the moment the rule is proposed, not from the moment you accept it — a proposal sitting in your queue already holds it, it just does not do anything yet.

Because a rule you accepted is your configuration rather than a calendar record, two things that erase calendar data leave it alone, both deliberately. The 90-day window in section 2.4 does not sweep it. Neither does disconnecting: your rules still apply to a calendar file you upload, and to any calendar you connect later, and quietly undoing a decision you made would be us overriding you rather than protecting you. (Rules you were offered and never accepted are deleted, content and all — when you disconnect your last calendar, and in any case once they reach the same 90-day window as everything else. A proposal you never answered is not a decision of yours we would be overriding.)

So it is kept until you remove it — and you can, from a screen. "Rules your calendar taught this timesheet", linked from the calendar page, lists every rule the product learned from you: the ones in force, the ones still waiting on you, and the ones you declined. Any of them can be deleted, and deleting one erases the value it remembered rather than archiving it — we cannot put it back. Hours you have already charged are untouched; a rule helped create them, and removing the rule does not reach into your timesheet.

Declining a rule and deleting it are different requests. When you decline a proposal we keep the row, and keeping it is precisely what stops us asking you the same thing again — so declining does not erase anything. Deleting does, and because the row was also the thing holding the question shut, the same pattern can be proposed again if it happens three more times. Both are yours to choose, and the product tells you which one you are doing before you confirm it.

3. What else we collect

3.1 When you visit our websites (we are the controller)

Our marketing sites collect what you would expect: pages viewed, referring source, approximate location from IP address, and device and browser information, via cookies and similar technologies.

We also use a visitor-identification service, RB2B, which attempts to match a business visitor's IP address and technical identifiers against third-party professional datasets — name, job title, company and LinkedIn profile — so we can tell which organisations are evaluating our products and follow up. This can result in us learning a name and business contact details for a visit in which you did not otherwise identify yourself. It does not identify every visitor; coverage varies by visitor and region.

You can opt out of this at any time, and we will not treat you differently for doing so. The quickest way needs no message from you at all: if your browser sends the Global Privacy Control signal we never load the service in the first place. See Do Not Sell or Share My Personal Information in section 7.1 for that and the other two routes, and for why we treat this as a “sale” or “share” under California law.

3.2 When you create an account (we are the controller)

Name, work email, the company you are joining, and authentication data. Passwords are stored only as salted hashes — we cannot read them.

3.3 What our customers put into the product (we are the processor)

Employee names and work contact details, time entries, timesheets and approvals, expenses and receipts, payroll figures, charge codes and project structures, and — where enabled — the calendar-derived records described in section 2. Some customers' use includes information about government contract work; we handle it under the same terms as everything else in this category.

3.4 Reading an uploaded receipt

Typing a receipt into an expense form is tedious and people get it wrong. So the product can read a receipt for you and fill in the merchant, the amount and the date, leaving you to check it rather than transcribe it. Doing that means sending the receipt image itself to a vision model, and a receipt is not a tidy record: alongside the merchant and the total it commonly carries a cardholder name and the last four digits of a card, sometimes an address, and whatever else the merchant chose to print. That is worth saying plainly, because it is the one place in the product where a picture of something from your wallet leaves our systems.

It only happens if you ask for it. Three things all have to be true, and any one of them not being true means nothing is sent:

• Your company has to be using expenses at all.
• Your company has to have turned receipt reading on. It is a separate setting from expenses themselves and it is off by default — a company that does nothing never has this capability.
• You have to choose it for a particular receipt, through a control that exists only for this purpose. Attaching a receipt to an expense the ordinary way does not send it anywhere; that is a different action, and it does not go near a model.

So this is not a background process and it is not applied to your expense history. There is no sweep, no batch, and no analysis of receipts you did not hand over for exactly this. What gets sent is the receipt you picked, at the moment you picked it, and what comes back is a draft you review before it becomes anything — the same shape as the calendar-derived entries in section 2.

The provider is Anthropic; Google (Gemini) is configured as an alternative for the same step, and which one runs is a platform-wide setting rather than a per-customer one. Both operate under terms that do not permit training on the data. We do not keep the image at the provider, and it is not used to build anything other than your own draft.

This is a different capability from the charge-code suggestion in section 2.7. That one is switched off everywhere and is not available to any customer. This one is available, off by default, and yours to turn on.

4. Who else is involved

We use a small number of vendors to run the service. Each is bound by contract to handle information only on our instructions, and none is permitted to use it for their own purposes.

The table below is for the current platform — TimerDB and Hour Timesheet. Customers still running Hour Timesheet 1.0 or Minute7 are on different systems with different vendors, and during a migration a customer can be on two at once. Those lists are kept separately, per product, at lmntl.ai/resources/sub-processors. We say which platform this table covers because the two Hour Timesheet platforms share a name and not a vendor set, and reading one for the other would be misleading in both directions.

The table above covers vendors that touch data inside the product. Our web application itself runs no third-party analytics or advertising scripts. Our marketing sites separately use Google Analytics, Google reCAPTCHA and RB2B, described in section 3.1. A current list is maintained at lmntl.ai/resources/sub-processors, and we update it before adding a new vendor that handles customer data.

We also disclose information where the law requires it, and in a merger or acquisition — in which case the acquirer is bound by this policy until it gives notice of a change.

5. How long we keep things

On termination we return or delete customer data on the customer's instruction, subject to any retention the law requires of us.

6. Security

• Everything in transit is encrypted with TLS.
• Data at rest is held in encrypted storage.
• Every customer's data lives in a separate database schema, and the boundary is enforced in the data layer rather than left to individual queries.
• Access to production data is limited to staff who need it, and is logged.
• Connections, syncs, confirmations and deletions in the calendar feature are written to an audit trail.

We are deliberately not claiming that stored calendar access tokens are individually encrypted at rest beyond the encryption of the underlying storage. They are access-controlled, tenant-isolated, and discarded whenever the connection comes apart — when you disconnect, when your employer's account is cancelled, and when their account is deleted (section 2.5). We would rather state that precisely than make a stronger claim we cannot stand behind.

No system is perfectly secure. If a breach affects your information we will notify you and the relevant regulator as the law requires.

7. Your rights

Rights depend on where you live, and on which of our two roles applies.

Where we are the controller — you may request access to, correction of, or deletion of your information; a portable copy; and you may object to or restrict certain processing. If you are in the EEA or UK you may also complain to your supervisory authority. If you are in California or another US state with a comprehensive privacy law, you have the equivalent rights under that law, and we will not treat you differently for exercising them.

Where we are the processor — send your request to your employer. If you send it to us we will acknowledge it, tell you who to ask, and pass it on to them.

Contact privacy@lmntl.ai. We respond within the time the applicable law allows, and we do not charge for a first request.

7.1 Do Not Sell or Share My Personal Information

The visitor-identification described in section 3.1 — matching your IP address and technical identifiers against third-party professional datasets, and using the result to contact you — may amount to a “sale” or “share” of personal information under the California Consumer Privacy Act as amended by the CPRA, and under comparable laws in other US states. Rather than argue that it does not, we treat it as though it does and give you the opt-out.

This applies only where we are the controller — our marketing websites. Information we process on behalf of your employer inside the products (your timesheets, expenses, payroll and calendar data) is never sold or shared, for any purpose, by anyone at LMNTL.

There are three ways to opt out, and you do not need an account for any of them:

• Global Privacy Control. If your browser or an extension sends the Global Privacy Control signal, we do not load the visitor-identification service at all on that visit — there is nothing to opt out of afterwards, because the match never happens. You do not have to tell us anything. Note that the signal is specific to the browser and device that sends it, so it has to be enabled on each one you use.
• Email us. Write to privacy@lmntl.ai with the subject “Do Not Sell or Share”. We will confirm when it is done.
• Use an authorised agent. Someone may submit the request for you. We will ask for written proof that you authorised them, and we may ask you to confirm it directly.

We will not treat you differently for opting out. No reduced service, no different pricing, no withheld content. Opting out does not stop you using anything on these sites or in our products.

We do not knowingly sell or share the personal information of anyone under 16 — see section 9.

Our marketing sites also use analytics and conversion-measurement cookies, described in section 3.1. Depending on how the underlying advertising platform is configured, some state laws may treat those as a share as well; the Global Privacy Control signal does not currently switch them off. You can refuse them in your browser settings, and the email and authorised-agent routes above cover them.

8. International transfers

We operate in the United States and process data there. Where we receive personal information from the EEA or UK we rely on Standard Contractual Clauses and the UK Addendum. Our data processing agreement is available to customers on request.

9. Children

Our products are workplace tools and are not directed to children. We do not knowingly collect information from anyone under 16.

10. Changes

We will post a revised policy here with a new effective date. For changes that materially reduce your rights we will give 30 days' notice before they take effect — by email to account-holders, or by notice in the product.

11. Contact

This policy is designed to address the requirements of the GDPR and UK GDPR, the California Consumer Privacy Act as amended by the CPRA, other US state comprehensive privacy laws, and the CAN-SPAM Act. It applies to TimerDB, Hour Timesheet and Minute7 alike.