Rev-Con-201 common mistakes
Rev-Con-201 · Understand the traps and how to avoid them.
Answers amendment, credit, and renewal scenarios as if each were a brand-new sale - describing a fresh quote, order, and invoice with no link back to the original subscription or revenue schedule.
Candidates carry over a linear order-to-cash mental model from general commerce, so the loop back from billing into the subscription and revenue schedule is invisible to them until a question forces it.
What to do instead
Redraw the lifecycle as a closed loop before studying: for each stage write the artifact it creates (quote, order/contract, subscription, invoice, revenue schedule) and, next to it, which later stages can reopen that artifact. Rehearse three loop scenarios - mid-term add, partial cancellation, renewal - end to end.
Traces data lineage by field label instead of by object relationship - for example assuming the quote line owns its own copy of list price, or that deleting a price book entry nulls the price already on a generated order.
The UI displays a resolved value on the line, which makes the line look like the owner of that value. Questions about which records change when a price, product, or configuration attribute is edited then get answered from appearance rather than from the reference/generation semantics.
What to do instead
Build a one-page object map with cardinality arrows and annotate each relationship as 'referenced live' or 'copied at generation'. Before answering any lineage question, locate the field on that map and say out loud whether the downstream record points at the source or stores a snapshot.
Chooses bundle versus standalone product structure from the catalog grouping or product name rather than from whether the components are priced and recognized independently, then builds a structure that cannot produce the pricing or revenue split the scenario requires.
Catalog taxonomy feels like the design driver, and the naming in many catalogs mirrors the packaging. Candidates model the product the way it appears in the catalog instead of the way the stem says it must be priced and recognized.
What to do instead
Before touching structure, answer two questions in writing: is any component ever sold outside the set, and does any component need its own price or its own revenue treatment? Only then pick the model. Practice by taking one packaged offering and rewriting it both ways to see which questions each structure makes unanswerable.
Assumes every configured discount or price rule applies and stacks them additively, instead of determining which rule wins by precedence and which rules are suppressed by contract pricing, segment pricing, or a volume tier.
Rules appear in a flat list in configuration screens and the evaluation order is never rendered as UI, so the visible set looks like the applied set. Stems that configure two overlapping rules are then answered by summing the discounts.
What to do instead
Memorize the evaluation order and the tie-breaker for equal precedence, then write it as a numbered list you can reproduce from memory. On every multi-rule question, state which rule wins and which are pre-empted before you look at the answer options - if the stem is silent on precedence, treat the winner as the thing being tested.
Assumes a quote-line edit propagates everywhere downstream, or the opposite - assumes nothing propagates - without separating fields that are synchronized from fields that are recalculated when the order or contract is generated.
Both behaviours exist in the same system depending on the field, but a candidate typically generalizes from the one demonstration or example they remember, so the answer flips depending on which field the stem happens to mention.
What to do instead
Keep a two-column table of synced versus regenerated fields and review it before the exam. Then treat effective dates (amendment effective date, co-term date) as a second independent axis, so each question is answered by picking one value from each column rather than by a general rule about 'changes flowing through'.
Prices an added line from the current date or from the original contract start date instead of the amendment's effective date and the co-term date, producing a proration that does not match the contract.
Stems phrase amendments as 'in month four the customer adds ten more seats', and candidates anchor on the date mentioned in the narrative or on the subscription's start date rather than on the three dates that actually govern the calculation.
What to do instead
For every amendment question, write down three dates before calculating anything: the new line's start date, the existing subscription's end/co-term date, and today. Prorate only from the new line's effective date to the co-term date, and state the number of days explicitly so an off-by-one-month error becomes visible.
Collapses invoice date, service period, and billing frequency into one concept - for example answering a billing-timing question by saying the customer is invoiced monthly 'because it is a monthly subscription', or asserting revenue is recognized on the invoice date.
All three values sit together on the same record, and in the simplest monthly-in-advance case they coincide, so the distinction never gets exercised until a stem deliberately desynchronizes them (annual prepay, arrears billing, mid-period start).
What to do instead
Answer every billing question by filling a four-cell grid first: billing cadence, invoice date, service period, payment terms. Then decide which single cell the question is actually about. Drill the three desynchronizing cases - prepay, arrears, mid-period start - until each cell can be set independently.
Treats credit memos, refunds, and cash receipts as revenue events - assuming a credit memo automatically reverses recognized revenue, or that collecting a payment increases revenue for the period.
All three post financial transactions against the same account and look similar in a transaction list, so they feel interchangeable. The separation between the receivables side and the revenue side is a modelling fact that is not visible in a transaction view.
What to do instead
Before answering, label each transaction in the stem as AR-side or revenue-side. Revenue moves only on schedule or performance-obligation events; credit memos, refunds, and payments adjust balances and aging. Any answer option that lets a cash or AR event change recognized revenue can be eliminated immediately.
Recognizes revenue at invoicing or at order booking on a multi-element deal instead of allocating the transaction price to each performance obligation and recognizing each on its own pattern.
Cash-timing intuition is strong and the single-line subscription examples used in early study reinforce it. Multi-element stems then get answered by matching revenue to invoice dates, and mid-term quantity changes get treated as a simple edit rather than a new segment requiring re-allocation.
What to do instead
Use a fixed three-step script for every revenue question: list the performance obligations, state the standalone selling price used for allocation, then state the recognition pattern per obligation. Add a fourth step for any change scenario - does this create a new segment that requires re-allocation from the change date?
Answers reporting and analytics questions using total contract value or invoiced-to-date totals as bookings, ARR, or recognized revenue, without checking which object the report is built on and which date field drives the period.
The numbers on a contract or account record look authoritative and are easy to recall, while the report's object and date basis are buried in configuration. Candidates therefore substitute a number they can picture for the metric the question actually defines.
What to do instead
For any reporting question, write the metric definition first (which object, which date field, gross or net of credits, annualized or period) and only then pick the figure. Practice by defining bookings, ARR, billings, and recognized revenue side by side and noting which date field each one keys off.