---
title: Email notifications
description: The seven emails inletAP sends, what triggers each and who gets it, why all are on by default, and how one person turns one off for themselves.
section: Reference
order: 34
---

# Email notifications

inletAP sends seven emails. Every one of them names something already happening in a workspace you are responsible for — an invoice waiting on your signature, an export that stopped, a bill that went past its deadline — and every one of them is on by default for every member.

That default is deliberate rather than lazy. A message nobody switched on is a control nobody has, so the switches would be decoration: the product would be silent until somebody went looking for a screen they had no reason to know about. The cost of being on by default is an email you did not want, and turning one off takes two clicks and affects nobody but you.

None of these emails advertises anything, and none of them is a newsletter.

## The seven

| Email                                                   | What triggers it                                                            | Who receives it                                     |
| ------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------- |
| An invoice breaches its SLA                             | An invoice passes the deadline its approval tier gave it and still waits     | Everybody in the workspace with the switch on       |
| An invoice is waiting for my approval                   | A signature is asked for on an invoice, or on one building's share of one    | The named approver, and nobody else                 |
| An export batch fails                                   | An export batch finishes in a state a person has to look at                  | Everybody in the workspace with the switch on       |
| A reconciliation run finds differences                  | A nightly or on-demand run cannot match everything we posted                 | Everybody in the workspace with the switch on       |
| A rule quarantines a document                           | A coding rule holds a document back instead of routing it                    | Everybody in the workspace with the switch on       |
| A vendor needs mapping                                  | A vendor has no counterpart in the connected ledger, so its bills cannot post | Everybody in the workspace with the switch on       |
| Second Look sends me a weekly summary                   | Monday morning, whether or not anything was found                            | Everybody in the workspace with the switch on       |

Six of the seven are sent because something happened. The last is the only one that arrives on a schedule.

## What each one says

**An invoice breaches its SLA.** A sweep looks every fifteen minutes for invoices past the deadline their approval tier stamped on them that are still waiting on a person. One email covers everything that went overdue in that pass: vendor, invoice number, amount, how many hours overdue, the deadline in UTC, and — on a split invoice — which buildings have not answered yet, so the two approvers who have already signed are not chased for a decision they took. Twenty invoices are listed by name and the rest are counted. One overdue invoice links straight to it; several link to the [Inbox](/app/inbox).

![The approvals queue grouped by how much time is left: Overdue first, then On track, then No deadline.](/screens/approvals.png "The email names the invoices that went past their deadline. This is the screen it is telling you about.")

**An invoice is waiting for my approval.** Sent when the signature is asked for, and addressed to the person being asked rather than announced to the workspace. On a split invoice the email states the share that person is signing for — "$4,000.00 of a $12,480.00 invoice — Maple Court" — because mailing them the document total would ask them to approve a figure they may not be entitled to see. One person covering three buildings gets one email listing three slices, not three emails. An unsplit invoice with nobody named on the seat is the one case where the whole workspace is mailed: the request is a queue rather than a task with somebody's name on it.

**An export batch fails.** The destination, the batch id, how many items of how many failed, and the error your ledger returned. It says out loud that nothing is retried automatically until the cause is cleared, which is the part people assume the other way round. It links to [Exports](/app/exports). See [export failures](/docs/export-failures).

**A reconciliation run finds differences.** How many bills matched, how many did not, the run's own one-line summary, and up to five examples, each linking to the invoice it is about. Only a run that found differences sends one; a clean run and a failed run send nothing. See [reconciliation](/docs/reconciliation).

**A rule quarantines a document.** Vendor, invoice number, amount, and the name of the rule that held it — "quarantined by Unknown senders over $5,000" is the only part of that message anybody can act on. One email per document, linking to the document. See the [rules reference](/docs/rules-reference).

**A vendor needs mapping.** A vendor with no counterpart in the connected ledger — QuickBooks Online or Xero — cannot have its bills posted there. The email is keyed on the vendor rather than the invoice, so ten stuck bills from one vendor are one missing mapping and one message. Its button is labeled **Map this vendor** and opens the [Exports screen](/app/exports), not [Vendors](/app/vendors): the vendors list has no mapping control on it, and the matching rows live on the Exports screen's **Ledger setup** tab, one ledger at a time. You may have to open that tab yourself.

**Second Look sends me a weekly summary.** Monday at 11:00 UTC, which is breakfast in New York either side of daylight saving. It is the only scheduled message of the seven and the only one that arrives when nothing went wrong: "We checked 34 bills this week. Nothing needed a second look." That number is counted off the documents your workspace actually put through the pipeline, never estimated, which is what makes the quiet-week message worth sending — a reader who has been told it for a month knows what our silence means. In a week with findings they are listed worst-value first, with "and N smaller ones" for the rest. A workspace that received no bills and found nothing gets no message at all. See [Second Look](/docs/second-look).

## Each fact is reported once

A delivery is recorded before anything is sent, keyed on the workspace, the event and the fact it names. An invoice that goes overdue is reported once however many times the sweep runs over it; a queue message delivered twice sends one email. The trade is stated rather than hidden: if the system dies between claiming and sending, that one email is lost rather than duplicated. A missed message is recoverable from the screen it would have pointed at; an unexplained duplicate is not.

## The hard duplicate does not get an email of its own

Second Look's one blocking finding — a hard duplicate, the only thing in the product that holds a bill out of an export — has no notification type. It rides inside the approval request instead, above the invoice details, and rewrites that email's subject line to begin "Possible duplicate:".

This is a design decision and not an omission. The reader of an approval request is already looking at that invoice and deciding about that money, so the finding costs no new message, no new switch and no second visit to the inbox. A duplicate that arrived after the approval email was sent still holds the bill back at export; it is the [duplicate card](/docs/duplicate-detection) on the document that says so.

## Your switches are yours, and they are per workspace

The switches belong to your membership, not to the workspace. One person muting export failures mutes them for that person: their colleagues keep receiving them, and there is no route in the product that edits somebody else's switches. Nobody can mute you, and you cannot mute anybody.

They are also per workspace. If you belong to two workspaces you have two sets, and turning one off in one place leaves the other as it was.

Turning a switch off changes the email and nothing else. An approval you are muted for is still yours to give, still in [Approvals](/app/approvals), and still late when it is late.

## Before you start

- You need to be signed in. Every role can do this, including a read-only external approver: an unpaid volunteer who cannot turn the reminders down will mark the product as spam instead.
- You only need it for yourself. There is nothing to ask an administrator for, and nothing an administrator can do here on your behalf.
- Decide which email you want to stop. Muting the weekly summary also mutes the quiet-week all-clear, which is the half of it that makes our silence mean something.

## 1. Open your notification preferences

Open the profile menu in the top right — your name and avatar — and choose **Email notifications**. That is the only way in from the app, at every screen width; on a phone it is the same two taps.

You should now be looking at a card headed **Email me when**, with seven rows and a switch on each, above a line naming the address they change.

## 2. Turn off the one you do not want

Press the switch on that row. Each switch saves on its own, immediately, and a toast reads **Notification settings saved**. There is no Save button to press afterwards and no confirmation step.

If the save fails, the switch goes back to where it was and the message says so. It does not leave you looking at a setting that was never stored.

## 3. Check it stayed off

Reload the screen. The row you changed should still read off.

This is worth thirty seconds because the failure this feature must not have is a switch that looks changed and sends anyway. The switches are read back from the server, not from the browser, so a reload is a real check rather than a look at the same memory.

If the screen instead says it could not load your notification settings, the rows are drawn at the default — everything on — and every switch is disabled. That is the honest rendering of "we cannot change this right now", not a claim that your choices were reset.

## The one switch a workspace can overrule

The weekly Second Look summary is the only row that a workspace-wide setting can settle for you. The digest can be switched off for everybody under [Settings → Second Look](/app/settings?tab=second-look), and when it is, nobody in the workspace is sent one however their own switch reads. The row shows that outcome — off, greyed, naming the setting that decided it — rather than drawing a green switch that sends nothing.

If you are a read-only external approver, your browser is not allowed to read the workspace setting at all, so your screen cannot know. It says so in a sentence rather than guessing.

## There is no unsubscribe link, and that is on purpose

These are transactional messages. Each one names something already wrong in a workspace the reader is accountable for, and none of them advertises anything, so neither a postal address nor an opt-out is required on them.

An unsubscribe button would also be worse than useless here. Somebody who pressed it on an export-failure alert would silently stop being told that their invoices are stuck, and would have no idea which control they had used. What every message carries instead is a line saying you are getting it because email notifications are on for your account, and a link to the screen above, which is honest about exactly what it turns off. Our postal identity is printed under it, so an unexpected email claiming your invoices are late can be checked against a sender.

An email we sent months ago points at an address that is no longer a settings tab. It forwards to the same preferences screen, silently, because somebody following that link wants the switches rather than an explanation of a change they never knew about.

One thing the switches do not cover: if your address has hard-bounced or reported us as spam, it is suppressed, and nothing is sent to it. That is not a way to turn these emails off — it is a dead address, and the fix is to correct the address rather than to live without the mail.

## See also

- [Second Look](/docs/second-look) — what the weekly summary is summarising, and the workspace-wide digest setting.
- [Duplicate detection](/docs/duplicate-detection) — the finding that rides inside the approval request rather than getting an email.
- [Approval tiers](/docs/approval-tiers) — where the SLA deadline in the breach email comes from.
- [Export failures](/docs/export-failures) — what to do when the export email arrives.
- [Your account](/docs/your-account) — the address these emails are sent to, and how to change it.