Salesforce AP-223 CPQ and Billing Consultant Accredited Professional Exam Practice Test

A Revenue Cloud consultant leading scoping must have:

A – Excellent communication: Key for translating technical and business requirements.

B – Planning/monitoring/review skills: Required to drive structured discovery workshops.

E – Awareness of design pitfalls & mitigation: Ensures a scalable CPQ/Billing architecture.

Options C and D are irrelevant: competitor knowledge or sales quota experience are not key skills for scoping a CPQ/Billing project.

Scenario:

A customer has:

A posted invoice

A new order for the same account

Wants to add items without using invoice batches

The correct approach:

✔ D — Use Bill Now on the new order and consolidate invoicesSteps:

Run Bill Now on the new order → generates a new invoice immediately.

Enable Invoice Consolidation (Billing settings / Account level).

Combine invoice lines from the new invoice into the already posted invoice.

Salesforce Billing supports invoice consolidation even after one invoice is posted.

Why the other options are wrongOption

Why Incorrect

A — Credit then Bill

Unnecessary; original invoice is correct and should remain posted.

B — Bill Now + reparent invoice lines

Reparenting posted invoice lines is NOT supported.

C — Cancel and Rebill

Only used to correct errors, not to add new order items.

Thus D is the correct solution.

Efficient UAT in Revenue Cloud requires:

✔ B — Define acceptance criteria with the customerEnsures clarity on what “pass” means.

✔ D — Train UAT testers on the new functionalityUAT fails quickly if testers don’t know how to use CPQ/Billing.

✔ E — Finalize test plans before the build is completedEnsures UAT is ready and structured once the sandbox is available.

Incorrect options:

A: Consultants should NOT execute tests on behalf of customers.

C: Not all issues in UAT require change orders; many are defects to be corrected.

The requirement:

"Bulk discounts include previously purchased quantities for pricing calculations."

This refers to cross-order discounting, where historical quantities affect pricing on the new quote.

To support this:

✔ B – Contracts, Subscriptions and Assets should be populated with historical dataCPQ reads existing Subscriptions/Assets to determine previously purchased quantities.

Historical install base must be migrated for correct discounting.

✔ E – Discount schedules with Cross Orders checkedSalesforce CPQ includes an OOTB feature:

Discount Schedule → Cross Orders = TRUEThis allows the quantity tiers to consider historical purchases.

Incorrect options:

A Custom Action unnecessary unless data is external (not indicated here).

C Summary variables cannot aggregate off-contract historical quantities.

D Migrating invoices is not required for quantity-based pricing.

Thus, the validated answers are B and E.

A partner leading a Revenue Cloud Scoping session requires:

✔ A — Strong communication skillsEssential for facilitating workshops, documenting requirements, and aligning stakeholders.

✔ B — Effective at planning, monitoring, reviewingScoping is structured, requires:

Agenda control

Risk identification

Note capture

Validation cycles

✔ E — Understanding design pitfalls & mitigationCritical in CPQ + Billing, where poor scoping leads to:

Wrong pricing model

Incorrect renewal logic

Billing edge cases

Data migration problems

A good partner surfaces these risks early.

Why the wrong answers are incorrect:Option

Why Incorrect

C — Knowledge of competitor products

Not relevant to scoping Salesforce Revenue Cloud.

D — Experience with quota-carrying sales roles

Helpful but not foundational to scoping complex CPQ + Billing architecture.

Final answer for Q49 = A, B, E

Salesforce Billing uses Usage Summary to combine usage records per:

Billing period

Order Product

Rating characteristics

To simplify future usage uploads after amendments, Billing requires a stable reference to group or map usage lines.

✔ Matching ID is designed exactly for this purpose.It is:

Unique

Persistent across amendments

Used by external rating or mediation systems

Can be used as an External ID

Other fields cannot uniquely support usage upload reconciliation.

Thus, E is the correct answer.

Requirement:

Set Legal Entity on Order Product and OP Consumption Schedule in a scalable way.

Runs before insert, so no second update transaction is needed.

Scalable (bulk-safe, low CPU, no recursion).

Modern Salesforce best practice for field population.

Works consistently across:

Order Products

Usage/Consumption Schedules

Why D. Before-Save Flow is correctWhy not the others?Option

Why Incorrect

A. Workflow Rule

Deprecated, not scalable, cannot run before-save.

B. Custom Setting

Storage mechanism, not automation logic.

C. QCP

Only affects Quote stage, not Order Products or Consumption Schedules AFTER order creation.

Thus **D is the correct, scalable, and recommended pattern.

A governance structure is essential in every Revenue Cloud implementation.

It ensures:

✔ C — Clarity on roles & responsibilitiesAvoids confusion, ensures accountability.

✔ D — A communication plan between implementation team & customerCritical for issue management, design reviews, sprint planning.

✔ E — Alignment on assigned workEnsures no duplication, no missed tasks, and smooth execution.

Why A and B are incorrect:Option

Reason

A

Governance does not mean the team works independently.

B

Governance does not assign extra work to the customer.

Thus C, D, E is correct.

Salesforce CPQ renewal automation uses two fields:

Indicates future revenue

Should be set immediately when contract is active

Indicates the renewal quote has been created

Should be set near the contract end date

1. Renewal Forecasted2. Renewal QuotedThis matches Salesforce best practice:

Forecast early → Quote late.

Thus C is correct.

When users log in to Salesforce CPQ for the first time, the Post-Install Script must run.

This script:

Initializes CPQ user settings

Creates required calculation metadata

Ensures Quote + Quote Line permissions and defaults work

Enables Primary Quote logic

If an automation tries to set a new Quote as Primary, but the user has not run the CPQ post-install script, CPQ raises errors because internal references and fields are not yet initialized for that user.

This is a documented CPQ requirement.

Thus, A is correct, and all other options point to permission issues that do NOT cause this specific failure pattern.

The requirement is:

When configuring a bundle, if the customer has previously purchased a hardware firewall, the Hardware Firewall product option should be hidden during bundle configuration.

This means the Product Rule must evaluate immediately when the bundle configuration UI loads, so that the option is hidden before the user begins configuring.

Salesforce CPQ documentation clarifies the evaluation events for Product Rules:

Evaluation Events in CPQ Product RulesEvaluation Event

When it Fires

Use Case

Load

Fires immediately when the configurator opens

Use this when hiding options or preselecting options based on external or historical data, Assets, Subscriptions, etc.

Load and Edit

Fires on initial load and every time the user makes changes

Use when rules may need re-checking with every MODIFY step.

Save

Only fires when clicking Save

Use when validating configuration before saving (e.g., preventing invalid combinations).

Always

Fires during all events including load, edit, and save

Rarely used; typically only for enforcement rules.

You need the option hidden right when the configurator loads.

The rule uses historical data (previously purchased hardware firewall).That data does not change in real time during the configuration session.

There is no need to re-check during every selection or on save.

Why Load is the correct answer:Therefore, using Load provides:

Optimal performance

Immediate user experience consistency

No unnecessary re-evaluations

Overkill; runs multiple times unnecessarily.

Negative impact on performance in large quotes/bundles.

Why the other options are incorrect:❌ A. Always

Hiding an option at save time is too late.

The user should not see the firewall option at all if they already purchased it.

❌ B. Save

This re-evaluates the product rule every time the user interacts.

Not required because the “past purchase” condition does not change during configuration.

Adds unnecessary processing.

❌ C. Load and Edit

A Revenue Cloud project often requires enhanced document capabilities beyond native Salesforce CPQ or Billing.

✔ A — Contract RedliningRequires document collaboration, versioning, and clause-level redline—not native in CPQ.

AppExchange apps like Conga, Nintex, DocuSign CLM support this.

✔ B — WatermarksNot supported natively by CPQ Quote Templates or Billing invoice templates.

Requires 3rd-party document generation.

✔ D — Electronic SignatureSalesforce does not provide native eSignature.

Common tools: DocuSign, Adobe Sign.

Why the wrong answers are incorrect:Option

Why Incorrect

C — Invoice Generation

Salesforce Billing does generate invoices natively.

E — Attachments

Salesforce Files/Attachments are natively supported; no AppExchange needed.

For multi-level discount approvals in CPQ:

A – Identify backup approvers: Required because Salesforce Approval Processes must account for out-of-office or unavailable approvers.

D – Define discount thresholds for sales reps: Mandatory so the system knows when to trigger approvals.

E – Document approval levels: Ensures clear governance and reduces ambiguity.

Incorrect options:

B printing approval matrices is not a Salesforce implementation requirement.

C contradicts the purpose of approval controls.

Thus the correct answers are A, D, E.

ARR__c exists on Quote Line (SBQQ__QuoteLine__c) and must appear on:

Opportunity Line Item for pipeline reporting

Salesforce CPQ automatically syncs Quote → Opportunity Line Item when:

The field exists on both objects

The Field API Name and Field Type match

This requires zero automation, no flow, no price rules.

The question:

Which feature is needed to split Order Products into different Invoice Runs?

In Salesforce Billing, the feature that controls how order products are separated into different invoice runs is Invoice Group.

✔ Why Invoice Group is the correct answerThe Invoice Group field on:

Order Product

Order

Invoice

is used to:

Separate order products into different invoices within the same invoice run, or

Ensure specific order products are invoiced in different invoice runs entirely.

The Billing Engine evaluates Invoice Group when generating invoices:

Order Products with different Invoice Group values → will be generated on different invoices or different invoice runs, depending on the configuration.

This is the official Salesforce Billing mechanism for splitting invoice generation.

Salesforce seasonal releases upgrade all Preview sandboxes before production.

To ensure testing against the upcoming release, a consultant must do the following:

✔ A. Review status.salesforce.com for sandbox preview scheduleSalesforce publishes sandbox preview instructions, refresh cutoffs, and upgrade dates. Essential for planning regression testing.

✔ C. Determine whether the sandbox is on a preview or non-preview instanceCritical because:

Preview sandbox = upgraded BEFORE production

Non-preview sandbox = upgraded AFTER productionTo test early, the org must stay on preview.

Why D is NOT correct (even though your key said A, C, D)Salesforce does NOT allow you to "submit a ticket" to request sandbox upgrades.

Sandbox preview status is controlled solely by whether the sandbox is refreshed before or after the preview cutoff date.

This is explicitly stated:

“Support cannot move a sandbox to a different release level.”

— Salesforce Release Management Documentation

Therefore, A and C are correct, not D.

Why B is incorrectSalesforce does NOT upgrade all sandboxes at the same time.

Preview vs Non-preview determines upgrade timing.

The consultant discovers:

Multiple triggers

Workflows

Flows

Possibly recursion or conflicting automations… on the Opportunity, which is foundational for CPQ.

Salesforce Revenue Cloud Best Practice:Use one automation type (preferably Flow) to avoid conflicts, recursion, performance issues, and unpredictable ordering.

Too many automation types cause issues with:

CPQ Quote Sync

Opportunity → Quote event handling

Performance and CPU limits

Unpredictable execution order

Therefore:

✔ A — Recommend using a single automation type for best performanceThis aligns with:

Salesforce Well-Architected Framework

Salesforce CPQ implementation guidelines

General platform automation best practices

Why other options are incorrect:Option

Why Not Correct

B

Large Quote Threshold affects calculator performance, not Opportunity automation.

C

Multiple automation types is the problem, not the solution.

D

Accepting the current messy automation is not recommended before CPQ implementation.

Thus A is correct.

For a large Enterprise Revenue Cloud (Salesforce CPQ + Billing) implementation, the key themes in all Salesforce delivery guidance and project best practices are:

Governance and change control

Design-first, then build

Raising scope-impacting changes through the Project Manager

Architect accountability for solution integrity, PM accountability for scope/timeline/budget

Let’s walk through why C is correct and why the other options conflict with typical Salesforce CPQ/Billing implementation best practices.

1. Context of the ScenarioYou are in the Build phase and:

You already have a design with:

Multiple Lookup Price Rules implementing complex pricing.

New information emerges:

Additional pricing logic

External data stores that must be incorporated

Need to modify existing lookup rules

Need to create additional rules

Need API development (integration work)

This is not a cosmetic tweak; it is:

Scope-impacting (new integration/API work, new logic)

Design-impacting (pricing architecture changes)

Potentially timeline and budget impacting

Therefore, this triggers formal change control.

2. Why Option C is CorrectC. Communicate these changes to the project manager who will evaluate the impact to scope, timeline and budget then determine the next course of action

This aligns with standard Salesforce implementation and project governance principles:

Any change that affects scope, complexity, or integration must be raised to the Project Manager (PM)

Project Manager is responsible for:

Scope management

Timeline & milestones

Budget & resourcing

Managing change requests and stakeholder approvals

The PM will:

Evaluate impact with:

Solution Architect (for technical/design impact)

Tech leads / Dev leads (for effort estimation)

Decide:

Whether a Change Request (CR) is needed

How to re-prioritize sprints, adjust backlog

Whether additional budget / time is required

How to communicate to customer stakeholders

This preserves:

Design integrity (Architect still evaluated the solution)

Project discipline (PM governs scope/timeline/budget)

Traceability and documentation (updated design docs, backlog, CRs)

This is exactly how a large enterprise Revenue Cloud (CPQ + Billing) program is expected to run.

3. Why the Other Options Are Not AppropriateA. “Adjust as long as we're in build phase”A. Communication to the customer ongoing adjustment can be made as long as we're in the build phase.

Problems:

Implies uncontrolled scope creep:

“As long as we’re in build, we can just keep adjusting.”

No mention of:

Impact to scope, timeline, budget

Formal change control

Involvement of PM or Architect

In a complex CPQ/Billing implementation, this would:

Break governance

Risk missed deadlines and budget overruns

Create misaligned expectations with the customer

So A contradicts standard methodology and enterprise delivery practices.

B. “Implement then review with the Solution Architect”B. Implement the lookup price rules immediately then review with the solution Architect.

Problems:

Sequence is wrong:

You never build first and ask the Architect later on large-scale pricing and integration changes.

This can cause:

Misalignment with overall pricing architecture

Conflicts with other CPQ/Billing components (e.g., Amendments, Renewals, Billing logic)

Rework if the Architect has a different approach

Still no mention of PM or scope/timeline/budget impact.

This violates both design governance and project governance.

D. “Architect then immediate implementation (no PM)”D. Consult with the solution Architect first who will expedite the updates to the design documents, then implement the changes immediately.

This is closer, but still incomplete:

Good:

You involve the Solution Architect.

You talk about updating design documents.

But:

No involvement of the Project Manager.

No consideration of:

Impact to scope

Impact to timeline

Impact to budget

For “large Enterprise Revenue Cloud” projects, Architect ≠ PM:

Architect owns technical solution integrity

PM owns project plan, change control, stakeholder approvals

So D ignores formal change management which is critical at enterprise scale.

E. “If low effort, just do it; else next sprint”E. Gather more details, if it requires a low level of effort then implement immediately before starting the next sprint. Otherwise complete on the subsequent sprint.

Problems:

Consultant is unilaterally deciding based on “low effort”:

No PM.

No formal scope/time/budget impact evaluation.

This might be okay for minor cosmetic or non-functional changes in a small project, but:

Here we have:

Complex pricing

Multiple lookup price rules

External data store integrations

API development

This is never “just low effort”.

For a large enterprise Revenue Cloud implementation:

This bypasses governance, change control, and approvals.

So E promotes ad hoc scope changes, which is against standard practice.

4. How This Ties Back to Salesforce CPQ & Billing Best PracticesIn Salesforce CPQ and Billing implementations, especially when dealing with complex pricing logic and external integrations:

Complex Pricing (Lookup Price Rules):

Changes can affect:

Quote calculation performance

Sequential dependencies with Price Rules, Discount Schedules, QCP, Billing logic

May cause downstream issues in:

Orders, Invoices, Revenue Schedules, Amendments, Renewals

External Data Stores & API Development:

Introduces:

New integration patterns

Error handling, retries, timeouts

Security and governance requirements

Impacts:

Technical design

Test strategy (SIT, UAT, performance testing)

Possibly non-functional requirements

Because of that, Salesforce project documentation and implementation guidance emphasize:

Raising such changes via Project Manager

Having the Solution Architect assess and update:

Solution design

Integration architecture

Managing it formally as a change request if it affects:

Scope

Timeline

Budget

This is exactly what Option C describes at the right level of responsibility.

The user story states that sales users should inherit previously negotiated pricing when quoting for existing customers.

In Salesforce CPQ, the object that stores account-specific negotiated prices is:

Contracted Pricing (SBQQ__ContractedPrice__c)

This object overrides standard list prices during quoting based on:

Account

Product

Pricebook

Contract linkage

Therefore, in addition to migrating Accounts, Contracts, and Quotes, the missing legacy pricing data must be loaded into Contracted Pricing.

Correct CPQ Calculation Evaluation Order:

Internal Initialization

QCP — onInitialization()

Calculate Formulas (pre-calculation)

Price Rule — Before Calculate

Calculate Quantities

QCP — onCalculate()

Price Waterfall Calculation

QCP — AfterCalculate()

Option E is the only sequence that matches this.