Include only information the recipient needs to understand or act on the invoice. Keep passwords, authentication codes, private internal commentary and unnecessary personal data out of notes. The creator does not need those details to calculate an invoice or display payment instructions.
The payment and notes workflow treats content review separately from application privacy. Browser-local processing limits the app’s own transmission, but a downloaded invoice, screenshot or shared draft can still disclose everything you put into its fields.
Consider who may read the document
An invoice may pass from a purchasing contact to accounts payable, managers, advisers or another authorised service provider. Do not assume the first recipient will be its only reader. Write notes appropriate for that wider business circulation.
Ask what each sentence contributes. A delivery clarification may help the customer understand a charge. An internal dispute, employee assessment or private phone conversation may add no necessary invoice information and can expose material that belongs elsewhere.
Keep the supporting business record separate from the customer-facing explanation. Your internal evidence may need detail that the invoice does not. Preserve the relationship without copying every conversation into a document designed to identify supplies, amounts and instructions.
Exclude credentials and access secrets
Do not enter bank passwords, card security codes, one-time authentication values or account recovery information. They are not payment instructions and are not required by this creator. A free-text box accepting a value does not make that value appropriate to store there.
Likewise, do not include a private dashboard login or a link containing an access token merely to help the recipient find supporting evidence. Use an authorised document-sharing process that gives the intended person the appropriate access without exposing credentials in the invoice.
If a source record contains secrets, extract only the legitimate invoice facts. Copying an entire email into notes can bring signatures, quoted history and access links with it. Review pasted material before treating the draft as ready to share.
Minimise personal information
Use relevant business contact information rather than collecting extra personal details by habit. A named billing contact may be useful, while a personal identifier, home address or unrelated family information may be unnecessary for the invoice’s purpose.
Do not infer that a detail should be published because it appeared in an earlier business message. A conversation and an invoice have different audiences and uses. Where a particular personal detail is genuinely required, confirm the appropriate handling through your responsible business process.
For a fictional review, imagine a note copied from an email containing an employee’s private mobile number and an internal approval argument. The invoice may need only “Approved service period: September 2026”. Preserve the approval evidence internally and omit the unrelated personal and conversational content.
Keep payment facts in appropriate fields
A reference or instruction can be easier to review in its supported payment field than buried inside notes. Avoid duplicating critical values unnecessarily. Each copy creates another place where stale details may remain after an edit.
The comparison of notes and structured payment fields explains that role distinction. Moving text to a supported field improves organisation, but it does not create a missing banking integration or formal standards mapping. Keep unsupported requirements visible in your working record.
Do not use notes as an informal account vault. The current app’s optional draft storage is explicitly triggered and is not encrypted by the application. Saving locally does not establish that a shared computer or downloaded file is suitable for sensitive information.
Review every output surface
Inspect the invoice preview and any notes included in the intended final output. Review application JSON when it is part of the handoff, since a readable page is not proof that every stored text field has been checked. Line-item CSV has a different scope and is not a complete invoice review.
Before creating a public screenshot or demonstration file, replace real customer and payment details with fictional examples. Cropping one visible section may leave other sensitive information elsewhere in the document or file. Use a complete fictional draft for demonstration where practical.
After removing inappropriate content, export a fresh file. Existing downloads retain the old notes. Keep the intended final version clear under your normal record-handling process rather than assuming a local edit retracts an earlier shared copy.
A final notes review should ask whether every included fact is necessary, accurate and appropriate for the intended recipients. The creator supplies supported entry, preview and export functions; it does not decide your disclosure obligations or control what happens after a file leaves the browser. Apply the appropriate business privacy and sharing process to the resulting documents.
A practical final check
A useful test is to prepare a fictional invoice containing an obviously labelled demonstration access code in notes, then remove it before export. Check both the visible preview and the application data. This tests your content-review routine without using a real secret and demonstrates why a screen crop alone is not a complete privacy check.
Use fictional data throughout.