Solution Orders: Products and Services in One Contract

Customers increasingly buy outcomes rather than items: equipment plus installation, a maintenance contract, spare parts, and sometimes a subscription, all negotiated as one deal. In SAP S/4HANA, the solution order is designed for exactly this. It gives sales and service one document for the whole solution.

For revenue accounting, that convenience raises a question. If one commercial document fans out into several operational documents, how do you ensure ASC 606 sees the arrangement as what it is?

What a Solution Order Is

A solution order is a central document for an end customer that combines the products, services, and contracts offered to that customer. It targets service-centric businesses with contract-driven models, such as IT and business process outsourcing or multi-service providers.

A solution order can contain several item types, including:

• Sales items (stock and non-stock items, services, configurable items)

• Service items, service expense items, and service spare part items

• Service contract items, which can include recurring services

• Subscription items, in an integrated scenario with SAP Subscription Billing

• Project-based service items

Solution orders can be created manually in the Manage Solution Orders app or via API, for example from SAP CPQ. In a CPQ integration, an accepted quote can create a solution order, which then triggers follow-up documents such as a sales order and a service contract; the supported scenario depends on edition and release. Document flow visualization connects the solution order with its follow-up documents.

Availability of item types and integrations depends on edition and release, so verify the scope for your system.

Why This Matters for ASC 606

The solution order is a commercial wrapper. Fulfillment, billing, and revenue recognition happen in the follow-up documents. That creates two accounting tasks.

1. Identify the Contract

Under ASC 606, contracts entered into at or near the same time with the same customer are combined if they are negotiated as a package with a single commercial objective, if the consideration in one depends on the price or performance of another, or if the goods or services together form a single performance obligation (ASC 606-10-25-9). A solution order is, by design, often exactly such a package. Even if SAP splits it into a sales order and a service contract, the accounting contract may be one.

2. Identify the Performance Obligations

Each element still needs the distinct analysis under ASC 606-10-25-19 to 25-21. Equipment and a separately priced maintenance contract are commonly distinct. Equipment plus a significant installation or integration service may not be. Subscription periods may form a series. The item structure of the solution order should make each potentially distinct promise visible as its own item.

Revenue Recognition Options

Because revenue is recognized on the follow-up documents, the recognition approach follows them:

• Event-based revenue recognition handles service documents individually, for example recognizing service contract revenue over time based on the billing plan and service order revenue on completion. It is lean and real-time, but each document is evaluated on its own.

• SAP RAR builds revenue contracts with performance obligations from operational documents and allocates the transaction price based on standalone selling prices. With contract combination, items from several follow-up documents can be brought into one revenue contract, which reflects the ASC 606 view of a combined arrangement.

If the solution order regularly contains bundled elements sold at an overall discount, the allocation question becomes central, and RAR is generally the more appropriate tool. If items are priced at standalone selling prices and recognized independently, EBRR may suffice. Which document types each option supports differs by edition and release.

Design Decisions

• Carry a common reference. The solution order number, or a CPQ quote reference, should be available on every follow-up item so that RAR can combine contracts reliably.

• Align item categories with POB rules. Each solution order item category should map to a defined POB type, fulfillment type, and SSP logic.

• Define the trigger for each recognition pattern. Delivery, installation, coverage start, and service completion are different events. Make sure each is captured on the right follow-up document.

• Plan for changes. Adding a service or extending a contract after the initial order is a potential contract modification. Decide how it flows from the solution order into the follow-up documents and into revenue accounting.

Pitfalls

• Treating each follow-up document as a separate contract by default, which can understate the allocation of discounts across the arrangement.

• Collapsing distinct promises into one item for convenience.

• Mixing recognition tools within one arrangement without a clear rule which tool owns which item.

• Relying on billing as a proxy for revenue when the solution includes free or discounted elements.

Related Articles

• Service Contracts and Service Orders: Revenue Recognition with RAR or Event-Based Revenue Recognition

• Designing Bundles in CPQ with ASC 606 in Mind

• Extended Warranties as Separate Performance Obligations in SAP

The Bottom Line

The solution order brings products, services, and contracts for one customer into one document, but SAP executes the deal through several follow-up documents. ASC 606 looks at the economic arrangement, which often means combining those documents into one contract and allocating the price across all promises. Design references, item categories, and recognition triggers so that SAP RAR, or event-based revenue recognition where it fits, reflects that view. Revident supports this with human-governed automation, where agents prepare and reconcile, and finance governs the judgments.

Planning solution orders with ASC 606 in mind? Talk to our experts.