About
Who writes this, and what it is not.
An independent reference on Salesforce Revenue Cloud Advanced and Revenue Cloud Billing, written while implementing it.
Nathan Altmann
I am a Salesforce Revenue Cloud architect at Meir IT. I implement Revenue Cloud Advanced and Revenue Cloud Billing — catalogues, pricing, quoting, billing, tax, ledger routing and document generation — across six implementations in production, pre-production and demonstration orgs.
This site exists because of a gap I kept running into. The official documentation describes what the objects are, and does that well. What is missing everywhere is the layer underneath: what fails silently, where the documentation runs behind the schema, and which design decisions turn out to be expensive to reverse. That layer is what I write down here, as I hit it.
What I have actually built
Each line below links to the page it produced. That is the only form of proof worth offering.
- ProductCatalogues with bundles, classifications, selling models and dependent picklists — including one bundle carrying twenty-one hardware variants in three roles.Read what it produced →
- PricingPricing procedures, decision tables and adjustment schedules — and the element ceiling, met at 128 of 130 and solved with procedure plans.Read what it produced →
- TaxA full tax pipeline: legal entities, policies, treatments, rates and an Apex engine adapter written end to end — plus a country-driven tax code solved with no Apex at all.Read what it produced →
- BillingOrder to posted invoice with correct VAT, and the ledger assignment rules underneath — whose criteria cannot be edited once inserted.Read what it produced →
- DocumentsQuote documents generated on the pricing context definition, which removes the data-extraction layer entirely.Read what it produced →
- MigrationPricing configuration moved between orgs, and the reasons a procedure that works in one returns nothing in the next.Read what it produced →
Questions are welcome
If you are evaluating Revenue Cloud, implementing it, or stuck on something specific, ask. I would rather answer a precise question than publish a vague page about it — and questions are usually what tell me what to write next.
Corrections especially. If something here is wrong on your org, that is worth knowing: every claim carries its register, and anything that turns out to be wrong gets corrected or removed rather than softened.
How claims are labelled
Every substantive claim carries one of these, so you always know what you are reading:
- Salesforce docs documented by Salesforce, and we link to the page.
- Field experience observed on a real org, at a stated API version.
- Recommended pattern an architecture we recommend, with its trade-offs stated.
- To verify believed, not proved. Treat it as a hypothesis.
What this is not
- Not affiliated with Salesforce. No endorsement, no sponsorship, no privileged access. Salesforce, Revenue Cloud, Agentforce and related marks belong to salesforce.com, inc.
- Not a client showcase. No client is named, and no client data, screenshot or deliverable is published. Contexts are described by their shape only, and the build refuses to publish if an identifying name slips in.
- Not a substitute for your own org. Behaviour described as observed was observed on a specific org at a specific API version. Platform behaviour changes between releases. Verify before you build.
- Not exhaustive. It covers what I have actually done. The gaps are real, and I would rather have gaps than invented content.
On the Salesforce links
No Salesforce URL on this site is typed by hand. The build downloads the official tables of contents and resolves every reference against them; an unresolved link fails the build rather than reaching you. The guide version at the last build was Winter ’27 (API 68.0).