The revenue cycle

The revenue cycle is the set of activities that turn a customer's order into cash: taking and approving the order, delivering goods or services, billing, managing receivables and collecting payment. Practitioners often call it order-to-cash. For most organizations it is the cycle that matters most to the financial statements and to fraud risk, because revenue is the largest number on the income statement and the one that managers are most often under pressure to increase. Revenue recognition rules (covered in ACCT-211) decide when revenue belongs in the accounts; the revenue cycle's systems and controls decide whether the transactions behind that revenue really happened, were recorded completely and accurately, and were collected.

Ridgeback sells through two channels. Independent retailers order through a business-to-business portal or by email to the sales team, buy on 30-day credit terms and pay by electronic funds transfer. Consumers buy through the online store and pay by card at checkout. The two channels share the same inventory, product master and general ledger in the ERP, but their risks differ. Retail credit sales create receivables and credit risk; online card sales create chargeback and payment-processor reconciliation issues instead.

Activities, documents and data

The revenue cycle has four main activities. Sales order entry captures the order, checks the customer's credit and confirms that the goods are available. Shipping picks, packs and ships the goods and records the shipment, which is usually the event that transfers control to the customer and triggers revenue recognition. Billing creates the invoice and updates the customer's account. Cash collection receives and records payments, applies them to invoices and deposits them. Each activity produces documents and data, increasingly electronic: the sales order, the picking list, the packing slip and bill of lading, the invoice, the remittance advice and the deposit record.

Sales order entry and credit

Order entry is where many problems start. A wrong price, an unauthorized discount or a sale to a customer who cannot pay all begin here. In an ERP, the sales order draws prices from the price list and discounts from customer-specific agreements, so the controls over those master data tables matter as much as controls over the orders themselves. Sales staff should be able to enter orders but not change prices or customer terms; a separate pricing or sales operations role maintains them, and changes are logged and reviewed.

Credit control protects against selling to customers who will not pay. New retail customers complete an application, and the credit department sets a credit limit based on references, financial information or a credit report. The ERP then checks every order: if the customer's open balance plus the new order exceeds the limit, or if the customer has invoices more than a set number of days past due, the order goes on credit hold until the credit manager releases it. The release decision should be made by someone outside the sales team, because salespeople paid on commission have an incentive to approve risky sales.

# Ridgeback: automated credit check on incoming orders (illustrative)
customers = {
    1043: {"name": "Summit Trail", "limit": 20000, "open": 12300, "oldest_days_past_due": 12},
    1077: {"name": "Lakehead Paddle", "limit": 8000, "open": 2900, "oldest_days_past_due": 48},
    1102: {"name": "Coastline Gear", "limit": 15000, "open": 14100, "oldest_days_past_due": 0},
}
orders = [(9001, 1043, 6500), (9002, 1077, 900), (9003, 1102, 1500), (9004, 1043, 1500)]
MAX_DAYS = 30
for order_no, cust, amount in orders:
    c = customers[cust]
    reasons = []
    if c["open"] + amount > c["limit"]:
        reasons.append(f"limit exceeded by {c['open'] + amount - c['limit']:,}")
    if c["oldest_days_past_due"] > MAX_DAYS:
        reasons.append(f"invoice {c['oldest_days_past_due']} days past due")
    status = "HOLD (" + "; ".join(reasons) + ")" if reasons else "released"
    if not reasons:
        c["open"] += amount          # the approved order now counts against the limit
    print(f"Order {order_no} {c['name']:15s} {amount:>7,}  {status}")

Order 9001 Summit Trail      6,500  released
Order 9002 Lakehead Paddle     900  HOLD (invoice 48 days past due)
Order 9003 Coastline Gear    1,500  HOLD (limit exceeded by 600)
Order 9004 Summit Trail      1,500  HOLD (limit exceeded by 300)

Look at how order 9004 for Summit Trail is held even though it is small: the earlier order 9001 has already used most of the customer's headroom. Systems that check each order against the balance at the start of the day, rather than including orders already approved, let several small orders slip through and together exceed the limit. Testing that kind of logic is part of evaluating an automated control, as lesson 9 explains.

Shipping and billing

Shipping should happen only against an approved sales order, and every shipment should produce an invoice. In an integrated ERP, the warehouse confirms the shipment by scanning the goods, and the invoice is generated automatically from the shipment record using the prices on the order. This removes the classic manual risk of goods leaving the warehouse without anyone billing for them. It does not remove every risk: if the warehouse can ship without a sales order, or if staff can create invoices manually without a shipment, the link is broken. A periodic report of shipments without invoices, and invoices without shipments, is an important detective control.

Credit memos and price adjustments reduce revenue and receivables and are a favourite method for hiding fraud, because a credit memo can make a stolen customer payment disappear from the customer's balance. Credit memos should require approval by someone who does not handle cash, should be linked to a return authorization or documented price dispute, and should be reviewed in a monthly report by customer and by employee. Lesson 2 showed how documenting the returns process exposes gaps in exactly this area.

Cash collection and lapping

The basic control over cash receipts is segregation of duties: the people who receive or handle cash should not also record it in the accounts or reconcile the bank. Modern organizations reduce cash handling by having customers pay electronically or through a bank lockbox, where the bank receives payments, deposits them and sends the remittance data electronically. The ERP's cash application function then matches each payment to open invoices using the remittance information. Unmatched receipts go to an unapplied cash queue for review, which must be cleared promptly, because old unapplied cash distorts the aging and can hide errors.

Lapping is a classic receivables fraud that segregation prevents. An employee with access to both cash and the receivables records steals a payment from customer A. To hide the theft, they apply a later payment from customer B to A's account, then a payment from customer C to B's, and so on. The scheme needs constant attention, so lapping is often discovered when the employee goes on vacation and someone else applies the cash. Controls include separating cash handling from recording, mandatory vacations and job rotation, sending customers monthly statements, and investigating customer complaints by someone independent of the receivables clerk.

Revenue cycle performance measures

Controls keep the cycle accurate; performance measures tell managers whether it is working well. Common revenue cycle measures include days sales outstanding, the percentage of receivables more than 60 or 90 days past due, bad debt write-offs as a percentage of credit sales, the share of orders shipped complete and on time, the number of credit holds and how long they take to release, the value of credit memos as a percentage of sales, and the share of cash receipts applied automatically without manual matching. Each measure can be produced from ERP data with the kind of queries shown in lesson 4. Trends matter more than single values: a steady rise in credit memos, for example, may point to pricing errors, quality problems or a control weakness in the returns process.

Measures can also create pressure that undermines controls. If the sales team is rewarded on shipments at quarter end, it may push goods to retailers before they are needed, a practice called channel stuffing that inflates revenue now and returns later. Comparing sales in the last week of each quarter with other weeks, and returns in the following month, helps detect it. Revenue cycle design therefore has to consider incentives as well as procedures.

Online sales and payment processors

Ridgeback's online store adds a different set of controls. Customers pay by card at checkout, and a payment processor settles the funds to Ridgeback's bank, usually a day or two later and net of processing fees, refunds and chargebacks. The ERP records the sale and a receivable from the processor; the settlement clears that receivable. A daily three-way reconciliation compares orders in the store, settlements reported by the processor and deposits in the bank. Differences point to failed orders, refunds not recorded, fee changes or, occasionally, fraud. Ridgeback should never store full card numbers; the processor's tokenization means the store holds only a token, which keeps most of the card-security burden of the Payment Card Industry Data Security Standard (PCI DSS) with the processor.

Sales tax adds complexity in Canada. Ridgeback must charge GST and the provincial portion of HST, or GST plus provincial sales tax, depending on where each customer is located, and the ERP's tax engine determines the rate from the ship-to address. Errors in the tax codes on customer or product master records cause systematic under- or over-charging, so tax configuration changes need the same approval and testing as any other master data change.