Discovery sees apps and destinations. Endpoint DLP sees pastes and uploads. To see where a typed customer address goes, you need a field-level test in Edge DevTools.
Someone in sales needs to bill a one-off customer before the month closes. The ERP has no record for this customer, so they search for a free invoice template, land on a web tool and type in the customer’s name, address, email, line items and amounts. Two minutes later they have a PDF. Nobody filed a request, and nothing was installed.
For a Microsoft 365 admin, the useful question is not “should people do this?” It is “what can my tooling actually tell me when they do?” The answer depends on which layer you look at. Each layer answers a different question. None of them, on its own, answers the one that matters most: did the typed customer data leave the browser, and who received it?
This article goes through those layers. It uses a measurement we published of 44 free invoice generators to show why the gaps matter. It is general information about tooling, not legal or data-protection advice.
What a measurement of 44 tools found
On 5 September 2026 we ran 18 fixed search queries for free invoice tools and kept one page per domain from the top results. That gave 44 third-party tools. We opened each one in a fresh browser context with no history and no extensions. We typed a unique “canary” string into every visible text field, a different string for each field, and then triggered the tool’s main action (download, generate, preview and so on). We then searched the URL and body of every request made after typing began for the canaries. If a canary appeared, that field’s value had left the browser, and we recorded the domain that received it.
The test ran to completion on 33 of the tools. The results, from the published dataset:
- 25 never sent what was typed anywhere during the test.
- 8 sent it to a server. For 6 of those, the only recipient was the tool’s own service.
- 2 sent one field each to an unrelated company’s domain (
intercom.ioandunifyintent.com). Both results reproduced in a second session with different canaries. - Across all 44 tools, the median number of third-party domains contacted while an invoice was being filled in was 10.5. Half contacted 11 or more, and the highest contacted 162.
The limits are part of the result. Each tool was tested in one session on one date, using only the free flow without an account. “Did not leave” means no canary appeared in any request that session observed. It is not an audit of any company, its servers or its retention, and none of this is a finding of wrongdoing. The full method and its caveats are in the README that comes with the dataset.
Two points matter most for an admin. First, most tools kept the data local and a minority did not, so you cannot judge the whole category at once. Second, the typical well-behaved page still contacted about a dozen other domains, and that shapes what your logs will show.
Layer 1: Cloud Discovery sees destinations, not fields
Microsoft Defender for Cloud Apps Cloud Discovery analyses traffic logs from firewalls and proxies, the log collector, or the native Defender for Endpoint integration. It checks them against a catalogue of more than 31,000 cloud apps and gives each app a risk score. Microsoft’s documentation adds a caveat worth remembering: by default, Defender for Cloud Apps cannot discover apps that aren’t in the catalogue. A small invoice site may simply not be listed. In that case you would have to define it as a custom app.
Even when a site is in the catalogue, Discovery works at the level of apps, destinations and traffic volumes. In our sample, half the tools contacted 11 or more third-party domains while one invoice was being filled in. Discovery can show which catalogued apps and destinations a user reached. It cannot show whether the client-email field went to any of them. The canary test only recorded which domains received a typed value. It did not classify what the other domains were doing. Connecting a specific field to a specific recipient is exactly what the test was built to do, and it is a level of detail traffic logs do not hold.
What Discovery does well is governance. You can tag an app Unsanctioned. On its own, that doesn’t block anything, but it makes the app easy to monitor. Once the Defender for Endpoint integration is set up, unsanctioned apps are blocked automatically. Microsoft lists Cloud Protection and Network Protection in Defender for Endpoint as prerequisites, plus the Defender Browser Protection add-on for non-Microsoft browsers. You can scope blocking to device groups. Microsoft also documents warn-and-educate prompts, which may suit a finance team better than a silent block.
Layer 2: Endpoint DLP covers pastes and uploads, not typing
Microsoft Purview Endpoint DLP can audit or restrict Paste to supported browsers when the destination is a restricted service domain. It evaluates the pasted content itself, whatever label the source file carries. It can also act on uploads of sensitive files to restricted cloud service domains.
So if someone copies a customer block out of an Excel export and pastes it into a free invoice site, a correctly scoped policy has something to catch. But none of the documented endpoint activities covers a person typing an address by hand into a web form, and retyping is common for a one-off invoice. DLP narrows the problem without closing it.
Layer 3: A field-level check with Edge DevTools
When someone asks “is this particular site OK to use?”, you can run a cut-down version of the canary test with the Network tool in Microsoft Edge DevTools:
- Open a clean window, then open DevTools (Ctrl+Shift+J) and go to Network.
- Tick Preserve log so requests survive any redirect or page change.
- Right-click any column header in the request list and turn on the Domain column. It is hidden by default.
- Load the tool. Into each field, type a distinct, meaningless token that names the field, such as
zq-client-name-7731orzq-client-addr-7731. For email fields, use an address atexample.invalid. Never use real customer data for this. - Trigger the action your staff would use: download, preview, save or send.
- Press Ctrl+F in the Network tool and search for
7731. The search covers request headers, payloads and responses. Each hit shows which request carried which field. - For each hit, check the Domain column and open the Payload tab to see exactly what was sent. The 3rd-party requests filter shows, separately, how much of the page is other people’s code.
- If you need to keep evidence, use Copy all as HAR (sanitized). By default this leaves out cookies and authorisation headers.
Read a clean result narrowly. A search can miss a value that was encoded or compressed before sending. Behaviour can change with the next deployment. Anything behind a login, or anything triggered by emailing the invoice from inside the tool, needs testing separately. A hit is not automatically a problem either. A tool that openly says it stores invoices on its servers is being straightforward, and the real question is whether that service is one you have approved.
Putting the layers together
A workable stance for a small finance or sales team:
- Give people an approved path first: a template in SharePoint, the invoicing module you already license, or a tool you have checked. People often reach for a search when the approved route is slower than one.
- Use Cloud Discovery to find out which invoice sites people actually use. Unsanction the ones you have not reviewed, and where you can, use warn-and-educate rather than silent blocks.
- Scope Endpoint DLP paste and upload rules for customer and payment data to the finance group.
- Run the DevTools field test on any site someone asks to keep using, and write down the result with the date.
We build InvoiceWorkshop’s invoice generator, which builds the PDF in the browser and keeps drafts on the device. It was included in the same measurement, flagged as our own and left out of every summary figure. It deserves the DevTools check above as much as any other tool. The test only works if you apply it to every tool, including the one recommending it.
This article was written with AI assistance and checked against the cited sources.