How the Reusable Service Catalog Speeds Up Invoicing

The service catalog lets you save a reusable name, description, and rate once, then drop it onto any future invoice as a pre-filled line item instead of retyping the same details every time you bill for the same kind of work. It sounds like a simple convenience feature, and mostly it is — but a few specific behaviors around how saving and editing a catalog entry actually works are worth understanding, especially the part that surprises people: changing a rate in your catalog never touches an invoice you've already sent.

What a Catalog Entry Actually Stores

Each saved service is just three fields: a name, a description, and a rate. That's deliberately minimal — no tax category, no default quantity, no currency attached to the entry itself. When you pull a saved service onto an invoice, those three fields populate a new line item on that invoice, using whatever currency and tax settings the invoice itself already has. The catalog entry is a template for the parts of a line item that tend to stay constant — what the service is called, how it's described, what you charge for it — while the parts that vary per invoice, like quantity and which specific invoice it's attached to, are left for you to fill in each time.

Saving Uses the Same Endpoint for Create and Update

There's a single save action behind both creating a new service and editing an existing one, and which of those two things happens depends on what you pass in. If you save with an existing numeric ID attached, it updates that specific record. If you save without an ID — or with something that isn't a valid existing ID — the system falls back to looking for an existing service with the exact same name in your workspace. If one is found, that existing record gets updated rather than a duplicate being created. If none is found, a brand-new service is inserted.

The practical effect of this name-based fallback is that you can't accidentally end up with two catalog entries that have the identical name — saving a "service" with a name that already exists in your catalog will always update the existing one, not create a second entry sitting alongside it. If you genuinely want two similar-but-distinct offerings in your catalog, they need to have distinct names, even if the underlying work is nearly the same — something like "Logo Design" and "Logo Design (Rush)" rather than two entries both just called "Logo Design."

Editing a Rate Doesn't Touch Past Invoices — By Design

This is the detail that trips people up most often. When you add a saved service to an invoice, the name, description, and rate are copied onto that invoice's line item as independent values at that moment — there's no ongoing link back to the catalog entry it came from. If you later go into your service catalog and raise your rate for that service, every invoice you've already created using the old rate keeps showing the old rate, exactly as it was when you built it. Only new invoices, built after the rate change, will pick up the new number when you pull that service in.

This is the only sane behavior for an invoicing tool to have. If a catalog rate change silently rewrote every historical invoice that had ever used that service, it would retroactively change totals on documents you've already sent to clients, already gotten approved, or already been paid against — invoices are meant to be a fixed record of what was billed at the time, not a live view into your current pricing. The catalog is a convenience for building new invoices faster; it was never meant to be a source of truth that old invoices stay synced to.

Deleting a Service Doesn't Touch Existing Invoices Either

The same logic extends to deletion. Removing a service from your catalog only removes the reusable template — it has zero effect on any invoice that already has a line item copied from it, because that line item isn't a reference to the catalog entry, it's an independent copy of what the catalog entry contained at the time you added it. You can safely retire a service you no longer offer without worrying that doing so will alter or break any past invoice that used it.

Workspace-Scoped, Not Personal

Your service catalog belongs to your workspace, not to your individual user account — every member of a workspace who can create invoices sees and can use the same shared list of services, and any workspace member can add, edit, or delete a catalog entry, subject to whatever role permissions apply to invoice-related actions in that workspace generally. This is useful for teams: if one person sets up a well-described catalog of the agency's standard offerings and rates, everyone else billing on behalf of that workspace benefits from the same consistent naming and pricing without needing to maintain their own separate list.

Why This Is Worth Setting Up Even If You Only Bill a Few Recurring Services

Beyond the obvious time savings of not retyping the same line item over and over, a consistent catalog has a quieter benefit: it keeps your invoice line items worded identically across every client and every invoice, instead of accumulating slightly different phrasings for the same underlying work depending on how you happened to type it that day. Consistent line-item language matters more than it seems for two practical reasons — it makes your invoices easier to skim and trust at a glance, since a client who's seen "Monthly Retainer — Content Strategy" worded exactly the same way three months running has an easier time verifying it than one facing a slightly different description each time, and it makes your own historical invoices easier to search and analyze later, since consistent naming is what lets you reliably filter or total up "everything I've billed for this specific service" across your invoice history.

Interaction With Recurring Invoices

If you pull a saved service onto the source invoice for a recurring schedule, that line item is copied onto every generated occurrence exactly as it existed at the moment the schedule was set up — the same "copy, not a live link" behavior that applies to any other invoice. If you later raise the rate in your service catalog, the recurring schedule keeps generating invoices at the original rate indefinitely; the schedule has no ongoing connection to the catalog entry it originally pulled from, only to the line-item values baked into the source invoice when the schedule was created. To actually raise the price on an active recurring invoice, you need to edit the recurring schedule's source invoice directly, which is a separate action from updating your general service catalog — updating the catalog only changes what new, unrelated invoices will get if you pull that service onto them going forward.

A Practical Setup Checklist

For a workspace just getting started with the catalog, it's worth front-loading a bit of naming discipline before you have dozens of entries to clean up later: use full, specific names you'll still recognize a year from now rather than shorthand only meaningful today, write the description the way you'd want a client to actually read it on an invoice rather than as an internal note to yourself, and set the rate to whatever your current standard price actually is, since it costs nothing to update later but saves you from needing to override it on every single invoice in the meantime. None of this is enforced by the product — the three fields accept anything — but a little care at setup time is what makes the catalog actually save time later, instead of becoming one more inconsistent list you stop trusting.

The Name Match Ignores Capitalization

The name-based fallback used to decide whether saving updates an existing entry or creates a new one relies on the database's own text comparison, which is case-insensitive by default. Saving "Website Audit" and then later saving "website audit" — without an ID attached to either — updates the same catalog entry rather than creating two separate ones, because the two strings are treated as equal for matching purposes even though they're capitalized differently. This is a genuinely convenient default: you don't need to remember the exact capitalization you originally used for a service name in order to update it later, since anything that matches case-insensitively will find and update the same entry rather than silently spawning a near-duplicate. It does mean you can't deliberately have two separate catalog entries that differ only by capitalization — if you need visually similar but distinct offerings, they need a more meaningfully different name than a capitalization change alone.