Send an Invoice as a Link, Not an Attachment

You send a PDF. The client says the amount is wrong, or the billing entity should be their holding company, or accounts payable needs a PO number on it. So you edit the file, rename it invoice_final_v2, and email it again. Then AP asks for one more change. That loop can run for a week on a single invoice, and every round adds a new attachment that someone has to figure out is the real one.

A private link breaks the loop. Instead of mailing a file, you send one URL that always points to the current invoice. The client opens it in a browser, sees exactly what you see, and can act on it directly. No download, no version confusion, no wondering which attachment AP is looking at. Here is how to run your invoicing that way, and how to still hand over a PDF for the clients who genuinely need one.

Why the attachment is the problem, not the format

A PDF is a snapshot. The moment you attach it, it is frozen and disconnected from you. If anything needs to change, the only way to update it is to make a new file and re-send. The client cannot add their own PO number, cannot correct their billing address, cannot forward a live document to AP. They can only reply and ask you to redo it.

That is the whole reason invoices sit unpaid. The back-and-forth a static PDF creates is not a communication failure, it is built into the format. A link stays connected. When the client edits a field, you get notified. When they request a price change, you approve or decline it and the invoice updates in place. The URL never changes.

Sending the invoice as a link, step by step

The mechanics are short. Sign in with a magic link or Google, then create an invoice with your line items, bank details, payment terms, and branding. Set your invoice number and issue date. Those, along with your sender and bank details, lock the moment you issue, so no one downstream can quietly alter them.

Generate the private link and share it however you already reach the client: paste it into an email, a Slack message, a project thread. The recipient opens it without creating an account or signing up for anything. On the free plan the invoice carries a small "Powered by JupiterInvoice" footer, which a 12-dollar-a-month plan removes.

From there, the client works with the invoice instead of just receiving it. Four fields are theirs to edit directly:

• PO number
• Billing entity
• Billing address
• Accounts payable contact

You get notified on each edit and can revert any of them in one click if something looks off. For anything that touches money, line items, pricing, discounts, currency, payment terms, or the due date, the client submits a change request and you decide. This split between what a recipient can edit and what they can only request is covered field by field in the guide to sending an invoice without a PDF attachment.

When the numbers are right, the client approves. That version locks permanently. If you had made content changes along the way, each one created a new version (V1, V2, and so on), while PO and billing edits were tracked as amendments to the current version rather than a fresh copy. You always know which invoice is the real one, because there is only ever one link.

Handling the client who still wants a PDF

Some AP departments run on files. They import a PDF into their system, or they need something to attach to a payment record, or their process simply will not accept a URL. That is fine. Every invoice can be downloaded as a PDF straight from the link, so either you or the client can produce a file on demand.

The difference is timing. With the old workflow, the PDF is the invoice and it goes out cold. With a link, the PDF is a snapshot of an invoice that has already been reviewed, corrected, and approved. When someone downloads it, the PO number is on it, the billing entity is their real one, and the terms are agreed. You are handing over a file that AP has no reason to reject, which is most of what stands between you and getting invoices paid faster.

If a client insists on their own vendor portal instead, that is a separate situation worth handling on its own terms. The point here is narrower: for the everyday case, lead with the link and treat the PDF as an export, not the delivery method.

What you gain besides fewer attachments

Sending a link changes what you can see. You know when the invoice moves from Sent to Viewed, so you are not chasing a client who never opened it. If it sits unopened, that tells you something different from an invoice that was viewed and ignored, and it changes how you follow up before chasing it.

The link also handles the two problems that quietly kill invoices: a missing PO number and wrong billing details. Because the client fixes both themselves, before approval, the invoice that reaches AP already matches what their system expects. Fewer rejections, fewer resends, fewer emails that start with "quick question about the invoice."

The same link approach works for quotes too. Send a quote with a valid-until date, the client types their name to accept, and you convert it to an invoice without re-keying anything. And if you are billing at volume or want to generate invoices programmatically, there is a REST API and MCP server that produce the same links.

Start with your next invoice. Build it as a link, share the URL, and only export a PDF if someone actually asks. The week you would have spent on attachments is the week you get back.