# Revenue Cloud: the decisions that set the shape of everything after > Quote-to-cash implementations are decided by the product catalogue, and the catalogue is usually designed by whoever had a free afternoon. These are the decisions that set the shape, in the order they have to be made. - Source: https://synconai.com/insights/revenue-cloud-implementation-best-practices - Publisher: SynconAI (https://synconai.com) - Desk: Revenue & CPQ - Author: SynconAI Architecture Team, Solution & technical architecture - Published: 27 April 2026 - Updated: 29 August 2026 - Reading time: 11 minutes - Topics: Revenue Cloud, Revenue Lifecycle Management, Product Catalogue, Pricing, Quote to Cash ## Key points - The product catalogue is the schema of your commercial model, and everything downstream joins on it. It is a modelling decision that looks like a data entry task, which is why it gets delegated. - Only price that is calculated can be automated. Price that is negotiated can be bounded, recorded and approved, and trying to derive it produces a rule set nobody can reason about. - Every extra level of bundling multiplies the options, constraints, prices and amendment behaviours somebody has to maintain for the life of the system. - Amendments, renewals and co-terms decide whether quote-to-cash works, and they are almost always scoped last, after the shape that has to carry them is already fixed. --- ::: note **On the name.** Salesforce has renamed Revenue Cloud to **Agentforce Revenue Management**. Salesforce's own wording is that "Revenue Cloud is now Agentforce Revenue Management" and that you may still see references to Revenue Cloud in the application and documentation. This piece says Revenue Cloud throughout, because that is still the name on the product page, in most orgs, and in what people search for. Both names refer to the same product. ::: A quote-to-cash programme is staffed as a systems project and decided as a modelling one. Most of what determines whether the finished thing is usable gets settled in the first fortnight, in a spreadsheet called something like Product Import, by whoever had a free afternoon. [Revenue Lifecycle Management](https://www.salesforce.com/sales/revenue-lifecycle-management/), which Salesforce also brings to market under the Revenue Cloud name, can express an enormous range of commercial models. It will express a poorly considered one just as faithfully as a good one, and it will keep expressing it for years, because by the time the shape is obviously wrong there are signed contracts sitting on top of it. The decisions below are set out in dependency order. Each constrains the next, which is why taking them out of sequence costs money: a pricing model designed before the catalogue is settled gets redesigned when the catalogue moves underneath it. ::: takeaways Six decisions, in order: what a product is, how price is derived, how deep bundles go, how amendments and renewals behave, what finance needs out the other end, and who genuinely has to approve. The first four are expensive to revisit. The last is not, and treating them all as equally dangerous is its own failure. ::: ## The catalogue decides the project, and nobody treats it that way Ask a programme what its biggest risk is and you will hear integration, or data migration, or adoption. Ask what the product catalogue looks like and you are usually shown an export of the current price list with some columns added. The catalogue is the schema of your commercial model. Pricing reads it, bundling reads it, amendments read it. Invoices are produced from it, revenue is recognised against it, the forecast is aggregated from it, and every integration to an ERP or provisioning system joins on it. It is the one artefact every part of [quote-to-cash](https://www.salesforce.com/sales/cpq/quote-to-cash/) depends on, and it looks like data entry, which is exactly why it gets handed to whoever is free. Catalogue complexity, not user count or deal volume, predicts the size of the work. A flat catalogue of four hundred products is a smaller job than sixty products with three levels of bundling and region-specific option logic. That is also true when the project is a move between platforms rather than a first implementation, which is the argument made at greater length in [eight questions to answer before you move off Salesforce CPQ](/insights/questions-before-a-cpq-migration). ## What is a product, in your business? This is a modelling question and it is routinely answered as a data entry question. A salesperson means a thing that can be put on a quote. Finance means a thing revenue can be recognised against, on a schedule, with a tax treatment. Delivery means a thing somebody has to provision, staff or support. Those three definitions often disagree, and when they do, the organisation has three catalogues whether or not anybody has said so out loud. One of them wins the build, usually the sales one because sales is in the room, and the other two are reconciled by hand for the life of the system. The awkward questions are the ones that read as trivial: - Is a service tier a separate product, or an attribute of one product? - Is a region a product variant, or a dimension of price? - Is a professional services engagement a product, or a line with no catalogue entry behind it? - Is a usage-based charge a product, a rate on a product, or a billing artefact that never appears on a quote? - When the same thing is sold direct and through a partner on different terms, is that one product or two? None of these has a universally correct answer, and each one reads as obvious to whoever proposes it. What settles them is writing the definition down in plain language and having somebody from each of sales, finance and delivery read it aloud and say whether they recognise it. A definition that survives being read aloud to the person who runs the process is usually right. ::: note Settle who owns the product code at the same time. If the ERP issues it, the catalogue carries it and never invents one. If the CRM issues it, something has to push it outward. Reconciliation between bookings, invoices and recognised revenue happens on that identifier, and retrofitting it once contracts exist is a data project rather than a configuration change. ::: ## Pricing: what is calculated, and what is negotiated This is the most useful distinction in the whole exercise. Price that is **calculated** can be automated. Price that is **negotiated** can be bounded, recorded and approved, but it cannot be derived, because there is no rule behind it. There was a conversation. Sort every pricing behaviour you have into those two piles before anybody configures anything. Calculated covers list price by currency and region, volume and tier breaks, term uplifts, contractual escalators, package-level pricing where a bundle carries its own price rather than the sum of its parts, and any discount an agreed policy grants automatically. All of it is expressible, testable and safe to leave to the system. Negotiated covers the number a human chose because a deal needed to close. The system's job there is to bound it, capture it, route it for approval and make it visible again at renewal. That is a different job, and it needs guardrails and an audit trail rather than logic. ::: warn The classic failure is a pricing rule written to reproduce one deal. It works, it is never removed, and three years later the catalogue carries a set of rules that interact in ways nobody can predict and nobody dares delete. Every rule needs a stated commercial policy behind it and a named owner, or it is not a rule, it is a fossil. ::: Decide too where discount lives: on the line, on the bundle, or on the order. This one is quiet and expensive. Every discount report, margin view and pricing analysis for the life of the system is shaped by that choice, and changing it later does not restate the history you have already reported. ## Bundle depth: every level multiplies maintenance Bundling is where catalogues get elaborate fastest, because nesting always looks like it is buying clarity. Each level multiplies several things at once: the options available at that level, the constraints between them, the default selections, the price points, the validation rules, and the amendment behaviour of every one of those elements. A change three levels down has to be reasoned about at each level above it. That cost is not paid once at build. It is paid at every catalogue change, for as long as the system runs. The test is what the depth is for. If customers genuinely negotiate at that level, the depth is real. If it exists to encode a configuration rule that belongs in product rules, or to mirror how engineering thinks about the product, or to reproduce the ERP's item hierarchy, then it is depth borrowed from somewhere else and paid for here. Two levels covers most commercial models. Three is a decision worth writing down with an owner attached. Four is a maintenance commitment, and it should be made by somebody who will still be there to maintain it. Structure the catalogue around how the deal is negotiated and how it will later be amended, not around how the product is built. Those two shapes are frequently different, and the negotiated one is the shape a quoting system has to live in. ## Amendments, renewals and co-terms This is where quote-to-cash actually gets hard, and it is almost always scoped last, after the catalogue and pricing shapes that have to carry it are already fixed. Every one of these is a commercial policy question, not a configuration option: - A customer adds seats mid-term. Do they pay the price on the original order, the current list price, or the original discount applied to current list? - Do the added seats co-terminate with the existing subscription, or run their own term? - What happens to a committed minimum when a customer reduces quantity, and is a reduction permitted at all before the term ends? - What does a renewal inherit: the negotiated price, the discount percentage, or nothing but the product mix? - On a multi-year ramp, what does an amendment in year two do to the years that follow it, and to any agreed annual uplift? If nobody has decided these, the implementation decides them by default, and the default becomes policy the first time a customer is quoted under it. That is the worst way to set commercial policy, because it is set by whoever was configuring on a Tuesday and discovered months later by finance. Model them in the first weeks, using real historical contracts rather than a clean new-logo scenario. New business is the easy case. Pull the three most awkward amendments of the last year, quote them end to end, and see what the model does. The differences you find there are findings. The same differences found after go-live are incidents, and they arrive with a customer attached. ## What finance needs out the other end Quoting exists to produce something that can be billed and reported on. That requirement should be gathered before build rather than discovered during the first month-end close, which is the usual sequence. The most effective exercise we know is to work backwards. Take three real invoices of different shapes, and one real revenue report. Ask what quote lines would have had to exist for those documents to be produced without manual intervention. Frequently the answer is that they could not have been, and the fix sits in the catalogue rather than in the billing configuration, which is why this belongs before the catalogue is locked. Ask specifically for the billing schedule shapes in use, the tax treatments that vary by product or geography, how revenue is recognised for each product type, and how bookings, invoiced amounts and recognised revenue are tied back to one another. [Revenue Cloud Billing](https://www.salesforce.com/sales/revenue-cloud-billing/) is where much of this lands, and what it can do cleanly depends almost entirely on the shape of the data arriving from the quote. Get the definitions in writing while you are there: what counts as bookings, what counts as annual contract value, and where the line sits between net new and expansion. Those same definitions determine whether the forecast built on top of this is trustworthy, which is a related problem covered in [opportunity stages that mean something in a forecast](/insights/salesforce-opportunity-management-best-practices). ## Approvals, designed around who genuinely must approve Approval matrices grow by accretion. Somebody senior asked to be included once, and the level stayed. Before designing anything, pull the last twelve months of approval history and count how often each level rejected or materially changed a deal. Levels that have never changed anything are not controls, they are delay with a notification attached. An implementation is the one moment when you can propose collapsing them with evidence in hand, which is the only way that conversation succeeds. Design what remains around commercial risk rather than seniority: margin thresholds, non-standard terms, unusual payment schedules, anything that commits delivery capacity which does not exist. Then design the escape hatch deliberately, because there is always one. If it is not designed, it will be invented, and it will be a phone call that leaves no record. ## The decision sequence This is the table we work through before configuration starts. The third column is the point of it. These decisions are not equally expensive to revisit, and treating them as though they were produces a governance process that slows the cheap ones down while the costly ones are made quietly in a spreadsheet. | Decision | What it locks in | Cost of revisiting later | | --- | --- | --- | | What counts as a product | Every downstream join: pricing, bundling, billing, revenue reporting, provisioning | Very high. Live contracts have to be re-mapped and reported history does not restate | | Product identifiers and their owner | How CRM, ERP and billing reconcile with each other | High. Integration rework plus a break in historical reporting | | Calculated versus negotiated price | What can be automated, and what needs guardrails and approval instead | Medium before build, high once the sales team has built habits around it | | Where discount lives | Every discount report, margin view and pricing analysis you will ever run | High, and reported history does not restate itself | | Bundle depth | Maintenance cost per catalogue change, and amendment behaviour at every level | High. Restructuring bundles invalidates quotes and complicates amendments | | Amendment and renewal policy | What a customer can be sold mid-term, and what a renewal inherits | Very high. Contracts are already signed under the previous behaviour | | Billing and revenue outputs | Whether finance can invoice and recognise without manual work | High, and usually paid forever in month-end effort rather than once in a project | | Approval design | Cycle time, and where exceptions become visible | Low. This one is genuinely cheap to change, so do not over-govern it | Read down the third column and the sequencing argument makes itself. The decisions at the top are the ones made earliest, by the fewest people, with the least ceremony, and they are the ones that cost the most to undo. ## Where this goes wrong, and what to do instead Three failure shapes, each recognisable early enough to avoid. **The catalogue is delegated.** It arrives as a clean import, everybody is pleased with the progress, and the modelling debt is paid later at amendment prices. The fix is to treat it as an architecture deliverable with an architect's name against it. **Pricing rules are written to reproduce deals.** Each is defensible alone and the set is incomprehensible. The fix is a stated policy and an owner per rule, applied from the first rule rather than retrofitted at rule ninety. **Amendments are a phase two.** They get scoped after the shape that has to carry them is fixed, which is the same as deciding them by accident. The fix is to model three real amendments before the catalogue is signed off. The wider pattern is not specific to revenue. A decision costs what it costs to reverse, in proportion to how far its output has already travelled, and here the output travels into signed contracts within weeks. The general version of that argument is set out in [the data model decisions you cannot cheaply undo](/insights/data-model-decisions-you-cannot-undo). ::: tip One piece of housekeeping worth doing properly. Salesforce positions Revenue Lifecycle Management as its current platform for quoting, contracting and billing, and that is where new capability is being built. Direction of travel is not the same as a roadmap commitment about the products you are licensed for today, so confirm the status of yours with Salesforce or your account team rather than with a consultancy, ours included. ::: None of these decisions requires a platform expert to make. They require the people who run pricing, finance and delivery in one room, answering questions in a specific order, before anybody opens a configuration screen. Two or three sessions, and it is what makes the rest of the build boring.