Table of Contents:
Order to Cash describes the procedure for processing customer orders, applying payments to invoices, and matching payments to the cash received in a company’s bank account.
In this process, cash flows through numerous systems described in detail below.
Accountants perform Order to Cash reconciliations to ensure that cash has appropriately gone through these systems for each transaction.
Before diving into the details of Order to Cash reconciliation, let’s go over the Order to Cash process and why it’s crucial to accounting.
At a high level, Order to Cash (also known by OTC or O2C) describes the procedure for processing customer orders, applying payments to invoices, and matching payments to the cash received in a company’s bank account. The principles behind OTC are essentially the same across all businesses and industries. However, the mechanics and order of OTC procedures vary slightly for subscription business models.
This section will review a typical SaaS OTC process and the related journal entries at each step.
Let’s look at each OTC step for a SaaS business:
Step 1: Customer submits an order
The OTC process begins when a company receives an order. For many high transaction volume SaaS, customers place orders directly on the company’s website and then a billing or order management system immediately processes these orders.
Example: On Jan 1, the customer browses Widget Company’s online store and purchases a one-year subscription to access Widget’s photo editing software for $500.
General Ledger Impact:
Deferred Revenue impact.
| Debit | Credit |
| Deferred Revenue | $500 |
| Subscription Revenue | $500 |
Step 2: Company invoices the customer
General Ledger Impact:
This affects billed accounts receivable and helps you see how much of your receivables you will collect, giving important cashflow visibility.
| Debit | Credit |
| Billed Accounts Receivable | $500 |
| Deferred Accounts Receivable | $500 |
Step 3: Customer pays the invoice
The order in which Steps 2 and 3 occur in the OTC process varies by company and operating model.
For high-volume SaaS companies where customers place orders directly through the company’s website, customers must submit payment digitally before the order can be successfully processed (for example, a subscription purchase for Spotify). Once the customer provides payment information, the customer can complete checkout, submit the order for fulfillment, and receive an invoice for the purchase. Invoices should include order details and any discounts or taxes, where applicable.
In many other business models, order fulfillment and delivery may occur before invoicing.
Example (cont.): Widget Company collects the $500 annual fee for a one-year subscription upfront. At checkout, the customer pays using a credit card and submits the order. Next, the customer receives an invoice copy in their email.
General Ledger Impact:
*We’ll debit accounts receivable on the balance sheet instead of cash, since credit card transactions may take up to three days to successfully process.
Step 4: Company fulfills the order
| Debit | Credit |
| Deferred Revenue | $500 |
| Subscription Revenue | $500 |
Step 5: Company delivers order
After receiving payment and invoicing the customer, the company must fulfill and deliver the order. For most SaaS companies, fulfillment and delivery coincide simply by provisioning access to the software.
Example (cont.): On Jan 1, Widget Company received the completed order and provided software access to the customer. The customer can now access Widget’s photo editing software for one year.
General Ledger Impact:
No impact.
Step 6: Cash payment is recorded in the general ledger
The final step of the OTC process is to record the cash payment in the general ledger and relieve the accounts receivable balance initially created upon invoicing in Step 2.
Example (cont.): On Jan 3, the credit card payment is successfully processed, and Widget Company receives cash in the bank. The accounts receivable balance can now be matched to the cash received.
General Ledger Impact:
Note: Implementing an Order to Cash reconciliation process enables companies to match sales to cash received and provides accounting teams with additional assurance that revenue and deferred revenue are recorded correctly in the general ledger.
To scale efficiently, high transaction volume businesses optimize and streamline the Order to Cash process by finding ways to automate different steps like revenue recognition and Order to Cash reconciliations.
An Order to Cash reconciliation verifies the completeness of a sale or transaction across the company’s operational and financial systems. Its completion assures both cash and revenue balances.
Cash reconciliation involves multiple systems; typically, the cash balances across these systems don’t match.
The goal of an Order to Cash reconciliation is to account for all the differences between these systems.
Order to Cash reconciliation vs. bank reconciliation
Order to Cash reconciliations are often used interchangeably with bank reconciliations; however, these reconciliations occur at different steps in the accounting process and offer different levels of insight into transactions.
A bank reconciliation involves matching transaction amounts reported in a bank statement with those recorded in the general ledger to ensure that the cash balance in the general ledger aligns with the entity’s actual cash balance in the company’s bank account. While companies and banks record the same transactions, the time at which a company records cash in the general ledger often differs from the time at which their bank reports the associated change. A bank reconciliation typically occurs at the end of an Order to Cash reconciliation when you need to figure out how much money you end up with in the bank.
An Order to Cash reconciliation can be complex because it involves all the operational systems that touch that process.
This section outlines the four most common systems involved in an Order to Cash reconciliation. These systems can vary depending on company size, business model, or technological maturity.
Billing system:
A billing system creates and manages customer invoices that allow customers to pay for their purchases. Cash from billing systems represents how much cash is expected to be collected from sales.
Payment processor:
A payment processor relays customers’ payment information to a company’s bank and the customers’ banks to complete a transaction. It verifies payment legitimacy and provides instructions to banks for fund transfers. Cash from payment processors represents the final cash received by the company’s bank.
Company’s bank:
A company’s bank collects and deposits cash from transactions successfully processed by payment processors. It is the final system involved in Order to Cash reconciliation.
Revenue recognition system:
A revenue recognition system calculates revenue for the current period and liabilities for future deferred revenues. It ingests information from billing systems and payment processors to perform these calculations according to the company’s arrangements and policies.
Examples of various systems involved in a Order to Cash reconciliation:
| Operational/Financial System: | Examples: |
| Billing system | Zuora, Chargebee, Recurly, Sage Intacct |
| Payment processors | Stripe, Adyen, Braintree/PayPal, WorldPay |
| Revenue recognition system | Leapfin, NetSuite ARM, Blackline |
| Bank | Bank of America, JP Morgan Chase, Wells Fargo |
Generally, cash balances across these systems don’t match, which is precisely why accounting teams must perform Order to Cash reconciliations.
Common reasons for mismatch across these operational systems include:
Next, we’ll outline an example of what an Order to Cash reconciliation looks like after completion. An Order to Cash reconciliation needs to aggregate cash balances from the core operational systems and identify the reconciling items across these systems.
In an ideal scenario, irreconcilable differences should balance out and total down to $0, especially if Accounting diligently records every turn of their transactions in their books.
Order to Cash Reconciliation example
Order to Cash reconciliations ensure that cash and revenue balances are reported accurately in the financial statements. This assurance has several additional implications:
Without Order to Cash reconciliations, businesses will find their financial reports inconsistent and unreliable. This causes issues with audit and can raise questions internally about the Finance team’s credibility.
For instance, cash reporting can vary across operational and financial systems; for example, your reported cash in your billing and revenue recognition systems may record different cash positions. In this case, misstated cash in the revenue recognition system can lead to misstated revenue which has serious ramifications for both the company and the Finance leadership.
In another scenario, Accounting, FP&A, Tax, and Business teams may all report different cash numbers. Inconsistent cash reporting arises when a company lacks a financial source of truth, which could lead to wrong decisions using error-prone data like under or overpaying the company’s taxes or making the wrong recommendations for business growth.
A comprehensive Order to Cash reconciliation should include a four-way match across the following operational and financial systems.
Step 1: Determine the accounting period that’s being reconciled
Examples include 5/1/2020 – 5/31/2020, 1/1/2019 – 12/31/2019, or even 4/15/2020 – 5/15/2020.
Step 2: Download reports from operational systems
Billing system (cash report): All sales transactions that occurred within the accounting period.
Revenue recognition system (cash report): All sales transactions that occurred within an accounting period. Download all sales transactions (like cash), not all revenue recognized in the accounting period. This is because revenue will include sales from the prior period as well.
Payment processor (payout report): All payouts from the payment processor within the accounting period. Payouts are cash transfers from the company’s payment processor to the company’s bank account. Payment processors typically generate payouts in batched quantities meaning that sales transactions from multiple days can be batched into a single payout. For example, sales from 2/15 and 2/16 are batched into one payout on 2/16.
Then, you’ll need two versions of the payout report:
Bank (bank statement): Bank statements may include incoming and outgoing cash related to other business activity. The bank statement will need to be filtered to display only sales transactions.
Step 3: Calculate cash within each report
In the following example, we demonstrate how to calculate the total cash within each system.
Example:
The company made $2,000 in sales in March and charged 6% in taxes. The payment processor charged a 3% processing fee.
Answer:
For most subscription businesses, revenue is recognized as gross of any fees incurred related to the sale, like the payment processor fees, and net of any taxes collected.
Step 4: Identify reconciling items across the report
These should match when reviewing the same accounting period.
We’ll generally see differences here. As mentioned earlier, batched payouts can include sales transactions from more than one day; for example, sales from 2/15 and 2/16. To reconcile, we need to identify the payouts that include transactions outside the accounting period in question, such as a payout on 3/1 that includes transactions from 2/28. Once those payouts are identified, we need to exclude the specific transactions outside the accounting period from the total payout amount. These excluded transactions are the reconciling items for identified differences.
We’ll generally see differences here as well. This is due to payments from the payment processor recorded as cash in transit in the general ledger. These cash in transit payments will be the reconciling items for identified differences. Cash in transit is a notable component of the Order to Cash reconciliation process. It makes bank reconciliation much easier and enables Finance to see the cash in-flows into their bank account.
Example: The payment processor creates and sends a $100 payout to the bank on 3/31 at 11:50pm EST. The bank receives and records the cash receipt on 4/1 at 7:00am EST. For the accounting period 3/1 – 3/31, the payment processor cash will include the $100 payout, the general ledger will record the $100 payout as cash in transit, while the bank statement will exclude the receipt of $100.
In today’s global economy, companies almost always operate in more than one currency: companies sell to customers internationally. Moreover, intercompany transactions between subsidiaries, and interactions between the company, banks, and payment processors involve different currencies. These transactions cause currency differences on various levels.
Let’s define some terms related to currency exchange to understand the mechanics of the accounting principles for international businesses.
Transaction Currency: this is the currency in which the transaction originated.
Functional currency: IFRS Standard IAS 21 and FASB ASC 830-10-45-2 define functional currency as “the currency of the primary economic environment in which the entity operates (ie the environment in which it primarily generates and expends cash).” It’s also the currency that the entity or company would use to report stand-alone financials. Companies can have more than one legal entity with different functional currencies per entity.
Settlement currency: also known as payout currency, settlement currency is the currency used by the bank account and the payment processor.
In the following example, we determine the appropriate transaction, functional, and settlement currencies Widget Company should use.
Example #1:
Widget Company is an online store that sells one-year subscriptions to access Widget’s photo editing software. Widget currently only sells its products in the US, Canada, and Australia, and allows customers to complete purchases in one of three currencies: USD, CAD, AUD.
Widget’s legal entity structure requires all customers in the US and Canada to be recorded in the US-based subsidiary (Wid-US), while all customers in Australia are recorded in the International subsidiary (Wid-Intl). Financial statements for Wid-US and Wid-Intl are prepared in USD and AUD, respectively. Widget’s payment processor and bank both only operate in USD.
On 3/1, a customer located in Perth, Australia purchased a one-year subscription for $100 and elected to pay in CAD.
Answer:
Transaction Currency: $100 CAD
Although the customer is in Australia, they can pay in USD, AUD, or CAD. This customer chose to pay in CAD.
Functional Currency: $109.94 AUD
Because this customer is located in Australia, the sale must be recorded in the international subsidiary (Wid-Intl), which has a functional currency of AUD. The exchange rate on 3/1 is 1 CAD to 1.0994 AUD
Settlement Currency: $71.72 USD
The payment processor and the bank operate in USD. Therefore, the payment processor will be required to convert the $100 CAD into USD to deposit the cash into the bank account. The exchange rate on 3/1 is 1 CAD to 0.7172 USD
Note: We ignore processing fees in this example for simplicity purposes.
Each foreign currency transaction is subject to foreign exchange (forex or FX). As shown in Example #1, the three different currencies require FX rates depending on the interaction.
FX rates fluctuate day by day. Changing FX rates will also impact a company’s realized gain/loss on its financial statements.
Realized gain or loss indicates that the customer has settled the invoice or the company has settled the refund. Changes within the functional currency (the currency used to prepare financial statements) result in FX gains and losses. Gains and losses are reported on the income statement; therefore FX differences in the functional currency will be the primary driver of foreign exchange.
In the following example, we outlined appropriate journal entries booked to the general ledger.
Example #2:
On 3/1, a customer in Perth, Australia purchased a one-year subscription for $100 and elected to pay in CAD. On 3/5, the customer cancels the subscription and receives a full refund.
The exchange rate on 3/1 is 1 CAD to 1.0994 AUD.
The exchange rate on 3/5 is 1 CAD to 1.0810 AUD.
Answer:
Timing differences across the various operational systems will cause differences in cash. These typically include differences between billing and revenue recognition systems, payment processor payouts, payment processor payouts, and bank cash.
These timing differences become more prevalent in companies with small dollar, high transaction volumes. Therefore, performing an Order to Cash reconciliation is essential to identify the reconciling items across each report.
Timing differences are often tedious to identify at month-end, especially when Order to Cash reconciliations are performed manually. Companies should consider automating their Order to Cash reconciliation and matching process to decrease the risk of manual errors.
When performing Order to Cash reconciliations at the aggregate level, it’s possible that you may not be able to identify differences down to $0. In such instances, accountants must define allowable differences or an acceptable threshold.
A threshold of <1% may be appropriate for some SaaS companies but not others. Accountants must rely on professional judgment and general rules of thumb to establish threshold levels. They must also consider the dollar amounts, percentages, and risk of material misstatement. An auditor’s opinion may be helpful, but ultimately, the accountant must determine the reasonable threshold.
Remember that it is all relative.
Companies with subscription business models typically have high transaction volumes, making transaction-level Order to Cash reconciliations extremely difficult without automation or finance tech stack modernization.
Aggregate reporting
When dealing with high transaction volumes, aggregate reporting is usually the default for accountants because they don’t have a cash matching system. Aggregate level reporting (as described in the examples above) allows accountants to perform high-level Order to Cash reconciliations and obtain comfort that sales and cash across an entity’s operational systems are complete and equally accounted for. However, aggregate reporting doesn’t allow accountants to drill down into specific transactions to identify discrepancies and reconcile items easily.
Transaction-level reporting
An ideal Order to Cash reconciliation is performed at the transaction level. An automated cash matching system can link cash from the various operational systems at the transaction level and identify specific differences. With transactional-level reporting, companies can reconcile on the lowest level, reducing discrepancies and reconciling items to $0.
“An ideal Order to Cash reconciliation is performed at the transaction level. With transactional-level reporting, companies can reconcile on the lowest level so discrepancies and reconciling items can be reduced to $0.”
While Order to Cash is the predominant reconciliation method for documenting transaction journeys and gaining insight into the company’s revenues, the current process by which OTC reconciliation occurs is largely manual, time-consuming, and error-prone, especially in fast-paced, high transaction volume business where every extra minute used to track down irreconcilable differences is a tradeoff for doing value-added tasks like tracking down revenue growth opportunities or plugging revenue leakage. To get there, Finance first needs to rethink the entire Order to Cash reconciliation process and understand how its crushing productivity and insight.
Order to Cash reconciliation usually stumps accountants, drains precious time and team morale and could lead to many challenges that crush the Finance team like tracking down irreconcilable differences across Finance systems or within financial reports. To automate and improve upon the process, Finance first needs to understand the challenges with the existing Order to Cash reconciliation process and how they impact the Finance team overall before seeking to modernize the Order to Cash reconciliation process.
Previously, we discussed how to conduct Order to Cash reconciliation processes in the right way. To do so effectively and keep up with the demands of today’s economy and customer expectations, Finance needs to pivot its thinking. In this section, we outline all the causes and consequences of a siloed Order to Cash process and how to address these challenges to help your Finance team drive future business success while freeing themselves from an endless reconciliation process. Built upon insights from hundreds of Finance teams like yours, we’ll unpack the seven pitfalls of the OTC process and how to break free and transform your finance operations.
Here are the seven reasons your existing Order to Cash reconciliation process is failing you and how to handle it.
One day, you discover discount codes are proliferating out of control. The next month, your assumption about dispute rates turns out to be way off, and you have to take a greater bad debt expense than planned, tanking the results. The month after that, you launched a new product with no visibility/segmentation to performance, and with the launch, engineering loaded a backfill that changed all your historical operational data. 😠
Today’s digital businesses grow faster, and are more operationally flexible than before. They might start as a subscription business in one country, but within a few years, operate in dozens of countries with different payment infrastructures and currencies and have additional marketplace or merchandise revenue streams.
A single ERP isn’t set up to handle this much complexity and to change so fast. Like in many other business domains, technologists have unbundled once highly-rigid monolithic systems function by function into a vast array of software services. The ERP has been kicked out of the Order to Cash game completely. Rather than being the system of record for Order to Cash, it’s just the system of final records for the general ledger.
To fulfill the core function of offering goods and services and getting paid, engineering teams have rightly focused on stitching the Order to Cash process with APIs and other integration methods.
But something essential got left behind in the process. In the urgency to adopt new payment processors, create new product functionality, introduce new business models, and more, the finance data produced at every step got completely disconnected, just like the operations data. And while engineering rightly prioritized connecting the operations data together to run the business, Finance was largely left behind in figuring out how to connect the dots. And that has made for an unholy mess.
Imagine a basketball game where every player keeps their score, rebound count, and shot clock. At the end of the game, the scorekeeper collects slips of paper with illegible handwriting from every player with their self-reported stats and tries to figure out the final score. That’s the challenge that finance teams face in figuring this all out.
Now imagine a tournament where the next game starts as soon as one game is finished. But there’s still only one scorekeeper. So during each game, they’re frantically trying to finish figuring out the score for the last game and can’t pay attention to the current game right in front of them. And the players from the last game are getting antsy because they want to know the result and which team to prepare to play next based on the bracket.
That’s one stressed-out scorekeeper!
The Finance team desperately wants to be engaged in the game right in front of them — to coach, to referee, and even to play — is so consumed trying to reconcile the stats for the last game they never have a chance.
Here’s what Finance’s reality looks like now. It’s not the tidy all-in-one Order to Cash process they keep trying to build:
Each operational system Product and Engineering teams use to support high-volume transaction processing — from taking an order, accepting a payment, fulfilling and shipping, handling disputes, and so on — only tells a part of the transaction story.
In the past, reconciliation was pretty easy — it mostly happened automatically in the ERP. The OTC process was tied to one data model, tracked in a single ERP system. Running the actual processing of orders, fulfillment, payments, collections, and cash was the game, and one a month, Finance powered the scoreboard.
Today, reconciliation is so much harder.
Instead of one data model residing in one system, the complex web of homegrown or standalone billing and order management systems, numerous payment processors, and app stores has exponentially increased the number of data sources that Finance teams have to reconcile.
APIs are everywhere, emitting data from a slew of disparate sources and structures in the tech stack:
On top of that, there are all the other data sources, like your bank and any internally developed software that emits financially relevant data, which is all of them.
Finance teams need to extract the relevant data from these systems to generate financial reports, often downloading huge CSV data files one by one, tie and reconcile it all together, analyze it, and then use it to build reports. The business logic they’re using to generate journal entries isn’t in a standardized, controlled system; it’s in innumerable spreadsheets, one typo away from a disaster.
With every additional transaction data nuance and every new data source, accountants risk making more manual errors, struggle even more to trace line items back from financial reports to source data and undertake greater contortions to reconcile accounts and close the books. As they get pulled deeper into spreadsheet acrobatics, financial analysts get farther away from advising and driving business.
These challenges slow business decisions and month-end close, reduce confidence in reporting and projections, and create unholy stress levels when auditors ask how the reporting relates to the source data from the operational systems. In turn, Finance is left with no time to devote to higher value work to root out waste, optimize accounting policies, or strategize with the business leaders about deploying financial resources to boost the bottom line.
Put yourself in the shoes of the Controller during an audit, and they get asked:
These are terrifying questions.
Worst of all, all the manual work — to reconcile, to close, to audit — means you aren’t maintaining the data at a transaction level and lose fidelity and detail with every step of the process. The detail that — if you had it at your fingertips — would be enormously valuable to optimize the business. For example:
It’s impossible to do these analyses accurately without a complete view of every transaction. And that view is just plain missing in today’s world of unbundled Order to Cash and manual finance acrobatics.
No wonder you feel frustrated. You’re stuck working harder and harder each month while delivering less and less value.
Let’s imagine, for example, that you need to understand net profit per order with orders in your ERP, payments in your PSP and selling expenses in your HRIS. To engineer that into your data pipeline, you need to write code to make a call to your ERP API that extracts data with a REST connector/authentication/validations API to get all the data in a JSON payload and load it into a central data store.
But you also need to tie variable commission expenses to your orders to get to net profit, and that data lives in your HRIS/Compensation platform, not your ERP. Unfortunately, that API requires us to send SOAP requests, and now you’re engineering a completely different authorization process which you then have to serialize from XML into JSON. Lastly, your PSP has a native integration to your ERP, but you spend more time tracking down and re-running failed transactions, entering missing records manually, and correcting transactions into their proper period. Instead, you go ahead and pull a raw data set directly from the PSP into a CSV and upload it to your data warehouse as a one-time backfill.
That’s just a rudimentary example using only data formats from common APIs and without touching on data structures and transformations to get you to the end state of the actual report or semantics layer where analysts can find value in the data! Performing gymnastics within these complex layers of your data stack all look like alphabet soup and take you further away from quickly getting the data you need to guide critical business decisions.
Excel works well enough when trying to process small amounts of data. But soon enough, you find your Excel models crashing, taking 20 minutes to open, or splitting into 37 files.
For digital businesses with high transaction volumes, Excel is no longer viable, and programmatic data processing methods also get stretched beyond their limits, causing data processing lags or failures.
For small datasets, it’s not uncommon to build pipelines using in-memory processes (like building Pandas data frames in Python and loading them into a data warehouse like Snowflake).
But as your datasets grow, you’ll hit a point where your infrastructure can’t handle the load (either by taking hours to run DAG pipelines or running out of memory entirely) and you need to move to a distributed process. And, forget about capturing changed data on massive data sets. That’s a whole other headache! Now if you’re processing data in your ERP and Excel, data is growing non-linearly, so hitting limits — on the API, concurrency, or on your contractual rights, or exceeding the Excel limits for a monthly close, isn’t at all uncommon. With historical operational data constantly shifting, you have no choice but to re-run and do a variance analysis across all historical accounting periods to know you’ve captured all data changes. That’s just one example of what drives this non-linear growth.
Exponential growth will hit you in the face much faster than you might expect. Can your ERP handle it? Sure, they’ll take your hundreds of thousands of dollars. Do you have that to spare?
It’s time to recognize the incredible disconnect between the beautiful vision of Order to Cash you’ve been working toward for thirty years, realize that it’s no longer viable, and shift your mindset.
It’s time to pivot your thinking from a horizontal view of Order to Cash – a view focused on process — to a vertical view, oriented around the data flows that are causing you so much heartache. In the vertical view, the focus is on taking operational data and translating and transforming it into finance data.
If you shift your approach from Order to Cash and pulling financial data at the end of a period to a new real-time data strategy, you unlock a whole new world of possibilities.
It’s how you can free yourself from the incredible weight of the scorekeeping process you currently manage and unleash your analytical and strategic finance firepower to lead strategic business change. It’s how you go from Finance being an afterthought and consequence of the operational activity in the business, to being a driver of the choices that lead to operational success. It’s how you go from being reactive to leading the business.
Finance can no longer afford to be on the sidelines in today’s market. High-growth digital companies today no longer have the luxury of unlimited and free capital. Finance leaders have to make sure every dollar is spent judiciously. You must find pockets of profit degradation from operational decisions made in a vacuum and do it immediately.
It’s time for a revolution in Finance thinking. Join us on the OTC to OTF journey. Let’s go!
For more information on how to rethink and automate your Order to Cash process, schedule a free consultation with one of our experts.