Managing Revenue Recognition, ASC 606, and IFRS 15
with FinancialForce Revenue Management
Jocasta: Hi, and welcome to this session on Managing Revenue Recognition with FinancialForce.
So, in this session, we are going to be covering how we automate revenue recognition across multiple revenue streams, and we’re going to be having a look at how revenue management can support ASC 606.
So, in terms of housekeeping, we want to keep this sort of interactive. If you have any questions as we go along, ask them via the question box on the right. We’ll monitor the chat box and answer some online. We’ll have questions and answers at the end of the session.
Technical issues: we hope you don’t have any, but if you do, there are a few suggestions here in terms of how we can help. If you continue having problems, do reach out to Global Events at their email address we’ve got in here.
So, we have the standard disclaimer in here. We are going to be covering items that are in the roadmap, and also items that are a relatively new functionality. So, the roadmap items are what we expect to deliver, but there’s no guarantee. So, just bear that in mind.
So what have we got lined up for the next 45 minutes? So, we're going to be looking at how revenue management sits in the context of FinancialForce and Salesforce. We're going to have a good demo looking at managing revenue recognition for professional services and subscription contracts. We're going to have a little overview of ASC 606 or IFRS 15 with a short demo so that you can see how the FinancialForce solution actually can help you comply with legislation. Then, we’ll finish up with a look at the whole roadmap and questions and answers.
So, I am Jocasta Perry. I’m a Product Manager with FinancialForce, and I’ve been with the organization for about five years. Richa Dubey is also on the call. She’ll be moderating and answering some of the questions, and she’s our Director of Billing and Revenue Management.
So, let’s have a look at how revenue management fits within the context of Salesforce and the other FinancialForce products. So, opportunities and quotes, obviously, on the Salesforce side of what’s driving our contract with the customer. This flows through into our best-of-breed FinancialForce products to deliver our end-services to our customers, and those flow through into Billing Central for invoicing and collections.
In terms of revenue management, the delivery systems, PSA subscription, billing and order management are tightly integrated with our revenue management solution. So, there’s a direct link from our service delivery to our revenue recognition. Our revenue management solution also supports revenue contracts for the revenue allocation that’s needed for 606.
Financials and forecasting and reporting are also a key part of our solution, and we have a real focus at the moment on Einstein and using the power of Einstein within FinancialForce as a whole. We're also using Einstein to support some elements of revenue management. So, our deferred revenue reconciliation is being delivered through Einstein, and we’ll have a little look at that in this session.
Then, we have the third revenue waterfall, which is something that’s coming up on the roadmap. This is all sitting on Salesforce. So, we've got that single platform with all our data in; that one single source of truth. We have that single integrated view of the customer from the opportunity to cash. So, I’m really providing that single integrated solution.
So, in terms of the scope, drilling in a little bit to revenue management. The solution really provides a number of different ways that you can recognize your revenue so that you can choose the method that's right for your organization. So, we support different ways of calculating the revenue that we're going to recognize. We can recognize revenue [unknown]. So, using that equal split of revenue each period. We have the percent complete method of recognizing our revenue, where you can choose what drives the percent complete, and that will drive the revenue recognition. We have a deliverable method of recognizing revenue, where once an item has been delivered to the customer, that triggers the revenue recognition.
We also support different periods. So, you might have a standard calendar, you might have a 4-4-5 calendar, and we support a number of different fine-tuned revenue recognition calculations within that.
In terms of recognition and forecasting, on the recognition side, we support multiple revenue streams, multiple currencies, and the ability to have kind of audit and control points along the process - if that’s what you want. The revenue management workspace has been delivered Fall 2020, so that’s a new item that’s just been delivered. We’ll have a look at the workspace and see how that can help the revenue manager manage that monthly process. And reporting: so, we can look again at the third revenue reconciliation report that we have through Einstein. So, we have a full suite of support of the recognition process.
In terms of forecasting, we have revenue schedules, which, a new element to revenue management. Revenue schedules are generating that forward-looking view of our revenue that we’re going to be recognizing, and that, at the moment, is something that works with revenue contracts and subscription billing. In service revenue forecasting, we have a whole deep-dive session, I think in a couple of weeks, on services revenue forecasting. So, if you want to find out more about that - more about the details of services revenue forecasting - do sign up for that session, and that will be a really exciting session, too.
No revenue management system would be completely without support for ASC 606. So, we have support for that in terms of generating revenue contracts, doing our revenue allocation in line with the legislation, and pulling our standard and selling price in from wherever it’s held within, perhaps, PSA or, perhaps, billing central - pulling that information through and into our revenue contract within Revenue Management.
So, with all that which I’ve said, you won’t be surprised to hear that our Revenue Management solution can take information from PSA, from Billing Central, from SCM. In itself, it supports the different calculation methods that I’ve mentioned in 606 report, and we have our revenue management flowing through into the FinancialForce general ledger, and we also have our revenue schedules in forecasting. But, what else we have is the ability that Salesforce - CRM or CPQ items - to drive revenue recognition or maybe forecasting.
Something that some of our customers find pretty useful is the way that revenue management can also pull information from other sources, as long as it’s on the Salesforce platform. So, it could be a third-party solution that you’re using, or it could be some custom objects that is part of your business, but isn’t part of our FinancialForce suite. The revenue management product can pick up information from anything, as long as it’s sitting on the Salesforce platform. We then have all the power of the Revenue Management project available for your custom and objects.
Then, also, we can - if we want to, if you’re not using the FinancialForce general ledger; which you should be, but if you’re not - for you, you have [unknown] SAP, or some other third-party general ledger, the FinancialForce Revenue Management solution can also integrate with that general ledger as well.
So, whilst the solution sits very well within the FinancialForce context, it can also support other non-FinancialForce areas as well.
So, having said all that, let’s have a demo and look at what the Revenue Management project looks like.
So, I’ve got a couple of scenarios here to go through. Our first scenario is looking at a time and materials project, or an opportunity - a single opportunity that’s driving a time and materials project - and a subscription and contract. We’re going to have a look at recognizing revenue from within the PSA and Billing Central so that you can see what we recognize. We’re going to have a little bonus extra looking at consolidated billing. So, how we can bring together the billing information from our project in PSA and our subscription contract together onto a single invoice for sending the customer.
Then, in our second scenario, we’re going to get into the details a little bit more of revenue management. We’re going to have a look at the different revenue recognition methods that we support. We’re going to actually run revenue recognition for a project. So, we’re having a live demo. Always good. We are going to have a look at the workspace and to see how that supports revenue management. We’re going to have a look at the deferred revenue reconciliation report.
So, let’s go to this demo. So, here we have an opportunity. This opportunity has three products, and these two products here are going to be driving a billing contract. So, a subscription contract. This third opportunity product is driving a time and materials project.
So, if we take a look at these opportunity products, our license opportunity is going to be, first of all, on the opportunity product. We’re defining how we’re going to be billing and how we’re going to be recognizing our revenue right up front on the opportunity. So, this first opportunity product, we’re going to be billing monthly. We’re going to be billing the same fixed amount monthly. We’re going to be billing $2500 a month.
On our Premium Support opportunity product, it’s going to be billed as a one-off, and we’re going to bill $15,000 as a one-off. In terms of our revenue recognition, we have decided we want to spread our revenue equally for both of these opportunity products, irrespective of how we’re billing them. So, we’re going to take that writable [unknown] method and, as we deliver these services to the customer, we’re going to be recognizing an equal amount of revenue every month for those two opportunity products.
But this time and materials, project-based opportunity profit, we’re not defining our billing or our [unknown] on the opportunity product here, because that information is going to be driven from the project itself.
This is about the setup side of things, really. We can then go and have a look at our billing contract that we got that has been created from that opportunity. We can see the contract lines here on our billing contract. These are pulling through all that information that we’ve already set up on the opportunity product. We’re bringing through the billing term, we’re bringing through the amount that we’re billing (obviously) onto the billing contract lines. We’re also bringing through on to the contract lines our total in a way of recognizing our revenue. So, we’ve defined that we are equally split revenue recognition methods. We’ve defined that on the opportunity product, and we’re pulling that through onto our billing contract lines to drive our revenue recognition.
So, we have a bit of extra information here on our billing contract lines. We can see how much we have invoiced, and we can see how much we have recognized already with these particular contract lines. So, let’s have a look and see what else we can see on this contract.
We can see our billing schedules. This is that forward-looking view of how we are going to be invoicing our customer, and we can see on our license contract line, we’re billing our $2500 every month. We can see from our Premium Support contract line, we’re billing this customer once $15,000. This is very much in line with what we would expect. We can see that these first two lines here, we’ve actually created a billing document that’s going to go out to our customer.
So, let’s have a look on the revenue side. Since we’re focusing on revenue recognition, we can see a very similar picture, in terms of our forward-looking revenue recognition. But, this is looking a little bit different from our billing. Here, we can see every month we’re going to be recognizing $2500 worth of revenue. But, this premium support line - which, you remember, was billed as a single $15,000 to our customer. We’re recognizing $1250, an equal amount, every month. So, there we can see that we’re able to bill as a one-off and recognize practically.
Let's have a little look at revenue recognition. So, this is the actual revenue we've recognized on these contract lines. We can see each period, we’re having the lines for each of our contract lines, and we're pulling in here. We can see the amount that we're recognizing, which matches up with our revenue schedules. We have the additional information here, showing the GL accounts that have been impacted by our revenue recognition. The GL accounts are coming from the products themselves, so the GL accounts are stored on the product. That comes through onto the contract lines and is then used on the actual revenue recognition transaction lines to drive our revenue.
So, that’s having a little bit of a look at billing and revenue recognition on this billing contract.
Let’s have a look at the time and materials project that we have created from that opportunity.
So, here, this is a time and materials project, as we said. So, our billing and revenue recognition is going to be driven from our timecard. So, we have four different time cards here, and each for 20 hours per week. We can see we are incurring $4,000 worth of charge on these time cards, billable to our customer each period. So, we can then look here at our revenue recognition again and have a look at how revenue recognition is working for our time and materials project.
As we can see here, revenue is being driven from our time cards, and we can see - similar to our billing contract - the amount that we’re recognizing each period, and we can see the general ledger accounts that are being hit for our revenue recognition. But we have some extra stuff for time cards; here, as can see - as well as the revenue that we’re recognizing - we’re also amortizing costs alongside our revenue recognition. So, we’re pulling our revenue from the time card and the costs from the time card. So, we’re keeping our costs amortized there, in line with our revenue recognition.
So, that was a time and materials project, with a sort of highlight in terms of how you can see the amount of revenue you’ve recognized and what you will be recognizing from within PSA and from within Billing Central.
But it would be nice to see how we actually go and recognize our revenue, and dig into it in a little bit more detail. So, back to what we were going to do with the second demo…
So, this is a fixed-fee project. We’re going to have a look at the fixed-fee project and how we recognize our revenue.
So, here, we have these different milestones driving our billing and our revenue recognition. So, this first milestone here for this project is one that we’ve chosen to recognize using the deliverable method. What this means is when this milestone is delivered, as the client-side PSA - so it’s not a criterion that revenue management is deciding - you decide what does it mean for us? When should our revenue be recognized? On the milestone? We have decided when it’s complete - when the status is approved and completed. Then, we should recognize all of the revenue for that milestone, and we can see it is in that status, and we can see that all of the revenue for that milestone has been recognized.
We have this second milestone in here. I’ve developed one which is open. So, this is in progress. We’ve chosen for this milestone, we’re going to recognize our revenue on a percent-complete basis. So, we have this field here on the milestone, and this is what’s going to be driving our revenue recognition. Now, this could be a field here where a person just goes and types in what the percent complete is. That could be useful if you want the project manager to have some input in terms of deciding the percent complete amount of that milestone. But, to be honest, it’s more likely that you may have a formulated field that works out how far along your milestone is based on information related to that milestone. So, it’s up to you to decide. The flexibility is there for you to decide how you calculate that percent complete amount. The Revenue Management solution can pick up that percent complete value, and use that to drive revenue recognition.
Here, we can see that this particular milestone at the moment is 40% complete, and we have recognized $4000 worth of revenue. So, that’s all looking nicely aligned.
Then, we have a look at the third milestone. Here, this is an equal-split milestone. So, what we’re doing is taking the total revenue - the $30,000 in revenue - and we’re spreading that between the start date and the end date of that milestone. We have made and recognized a good chunk of that revenue already.
So, let’s have a look at what the actual revenue recognition has happened for this particular project. We can see, similar to the other revenue recognition information that we’ve seen, we have the amount that we’re recognizing for each of the milestones shown in here. We have the GL accounts that’s being impacted by our revenue recognition. We can see by looking at the dates here that we’ve recognized up to August.
So, what I thought it would be exciting to do is actually recognize revenue for September. So, let’s make this project move on a little bit. Let’s open up this milestone. Let’s make the milestone progress. Now, I can do that nice and easily in the [unknown] by just typing a different number in. This is, obviously, to help me with the demo. As I said, this could be something that you have as a formative field that will pull the information from records underneath your milestone.
So, now, if I go back to this project and have a look at it. Look at the milestones underneath this project. We can see we’ve got extra revenue to recognize because this milestone is now 50% complete, but we’ve only recognized 40% of the revenue. So let's have a look here now at the revenue recognition product itself.
So, there were different ways that we could run revenue recognition. What I'm going to do here is the more manual way of recognizing revenue so we could recognize revenue for our different revenue streams. Here, we have billing contracts and project setup as revenue streams. We also support, as the slides showed earlier, revenue contracts, other areas and including custom objects. So that's very easy to set up. We just select the revenue date. We're going to recognize our revenue for September. What I'm doing here is filtering my revenue recognition so it's just running for prestige worldwide, so that I could do this in a demo.
So here, if we look at what we have now to recognize September for this particular project, we don't have any extra revenue to recognize for milestone number one because that's all recognized. So, obviously, it's not going to find anything else to recognize. That would be a bit wrong. Our milestone number two: that's our percent complete milestone. We have $10,000 worth of total revenue. We've already recognized $4000, as we saw from the project itself, and it knows that because we've completed an extra 10% of the milestone during this period, we have an extra 10% of revenue to recognize.
With our equal split milestone, we've done another month's worth of work. So we've got another month's worth of revenue to recognize. So what I can do is recognize my revenue for September. I can create a revenue recognition transaction Again, there are other ways of doing this. This is a way where you have a lot of control over the process.
So I've now recognized revenue for September, and I could go back to this milestone, and I can have a look at the updated project information. I didn't even have to refresh the page. So, here we have the milestone 50% complete, and now the amount of revenue that we've recognized, $5000 has gone up. So, it's now in line with what we would expect. We can see what we’ve recognized to date. It was $2100 and something. Now it’s $24,000. So, we’ve recognized another month’s worth of revenue for this particular project.
So that's relatively straightforward, and it really shows how tied together on our revenue management solution is with PSA, with Billing Central, with supply pain management, and we have a similar level of integration, obviously, with all these fields and custom objects if you want to be recognizing revenue on custom objects.
So, let’s have a look at the support for the revenue managers. So, we have our revenue management workspace. This is something that’s been delivered before, so this is relatively new. We have information here looking at the current month versus the previous month’s revenue so that we can have a look and identify what the difference is, so that it is a prompt in terms of whether you were expecting a big difference, one month on month. If there were any errors, you’re able to see them and act on them, and you can check the progress of your revenue transactions into the general ledger.
We have a nice visual representation of the amount of revenue that we’re recognizing each month. So, again, it helps you identify any peaks or troughs in your recognition that you might be expecting. We can see the details of our actual revenue recognition transactions here, if you wanted to drill into that and get a bit more involved in the detail.
Now, when I was actually recognizing revenue, I was going in and selecting a particular revenue stream recognizing revenue for a particular project. We have this also this recognizable functionality, which is a much more simple way of triggering the revenue recognition process, where we can just enter the period that we want to recognize our revenue for, the date that we want to recognize our revenue up to, and it will kick off a process that will recognize revenue for all currencies, all revenue streams and all companies. So this is that kind of one-stop-shop to recognize your revenue.
In terms of other support for revenue management, it doesn't stop there. We have, as I said, Einstein reports that help with your revenue recognition. So this deferred revenue reconciliation report is pulling information from our general ledger. So this is looking at our deferred revenue ledger, and we can do this reconciliation for a particular period. So, we can choose the account that we’re reconciling and the period. We’re looking at all the transactions that have hit our general ledger. We’re looking at the revenue we expect to recognize during this period, and we’re looking at the revenue that we have expected - additional revenue - to defer from billing documents. Then, we can pull that together and do the comparison. My helpful test data highlights that there may be an issue you want to go and see. So, it’s always good to demo those scenarios, where this is providing that extra value-add. We can see that movement on the general ledger, and then that movement from revenue management, and revenue recognition and revenue deferral don’t quite match. So, it’s just highlighting to the revenue manager that they need to go and look at that in a little bit more detail.
So, we’ve seen that: the process for running our revenue recognition. We’ve seen how we tie revenue recognition with Billing Central and with PSA. We’ve seen how workspaces help the revenue manager get the overall picture and also drill down into the detail, and we’ve seen the deferred revenue reconciliation and how Einstein can help with revenue management.
There is more! So, now we’re going to move on to looking at 606 and how the revenue management solution can help with 606. So, prior to that model, there are people who provide or compile financial statements. But, for those of you who may not be so familiar, the first step is really… What this is about is, it’s to help in a situation where you may be selling a group of items to a customer, and some of those items may have been discounted heavily by the sales guys. When it comes to recognizing your revenue, what you want to do is spread that. This comes out equally over all the items that you’re including for revenue recognition.
So, first of all, what we do is identify the revenue contract and the performance obligation. So, this is what we’ve sold to our customer, the performance obligations are the items that we’re delivering to our customer.
Then, determine the transaction price. This is just what the customer has paid for these things. So, nothing fancy there. The interesting bit, really, is allocating the transaction and allocating the revenue to the performance obligations. What we do there is we look at the standalone selling price of these different items that we’ve sold, and we allocate the revenue to the performance obligations, based on the ratio of the standalone selling price.
For those where some numbers might help you understand that a little bit better, we’ve got some numbers. We identify a revenue contract with delivering these three different items to the customer. The transaction price: the customer is paying $10,000 for this. It’s come from these different items underneath. Then, in terms of allocating the transaction price… So, if this customer had bought these three different items separately, they would have paid $16,000 for them, but they actually paid $10,000. So, they got a good deal from us. When we compare the standalone selling price to the actual individual at the line level, you can see that they got a brilliant deal on consultancy. They’ve only paid $1000 instead of $4000. They’ve got a little bit of a good deal on software licenses.
So, in terms of doing the allocation, what we do is we look at the proportion of the selling price so that we can see the software license is contributing half of the standalone selling price, whereas these two are contributing a quarter each if we had sold them on their own. So, for allocation, we just take this $10,000, we give half of it to the software license and a quarter each to those. So, hopefully, this illustration shows you that this isn’t complicated or scary.
Step five, which isn’t shown here, is the actual revenue recognition. So, what we do is we take these allocated revenue values, and these are the numbers that we’re going to use to drive our revenue recognition, instead of the actual amount that the customer was charged for that particular performance obligation.
So, in terms of how revenue management helps us with this, we have the ability to create revenue contracts. That can pull information from multiple sources together into the same revenue contract. We pull the standalone selling price in from wherever it’s held - whether that’s PSA, whether that’s Billing Central - and we automate that revenue allocation. There are options for overriding if you want to have some additional flexibility in those audit trails around that as well.
Then, we have support for the reporting. In terms of restating his current revenue and doing that reporting on 605 and 606.
So, we’re going to have a little demo of this as well. We’re going to have a look at the five-step model and what this actually looks like within our solution.
So, we have a revenue contract that covers professional services and subscriptions. We can see how we're creating our performance obligations, and in this example, we're grouping a number of items together into a single performance obligation because that's what delivers value to our customers. We can determine the total contract value, and then we can look at the standalone selling price and revenue allocation. Then, finally, we can see how we actually recognized revenue for our revenue contract.
So let's go over to our demo. We have this revenue contract here, and this revenue contract is pulling information from a billing contract. So we have this billing contract with a total value of $46,200. We have a product that is also contributing to this revenue contract. The project, as we can see here, that this is information on the project itself. We're getting $75,000 of revenue for this project, but our standalone selling price is $86,200. So, we can see that this customer has got a good deal from us because they've got a discount of just over $10,000 on this project. So that's step number one: looking at our revenue contract.
Step number two is defining our performance obligations. So, we've got four different performance obligations for this revenue contract. This accounting engine monthly performance obligation, I’ve just opened up over here, and we can see it's the same one. I'm not cheating. We can see that this performance obligation is pulling information together so there are multiple lines for this performance obligation that are coming from our billing contracts. So, our billing contract has these four different lines, and we're grouping them all together as a single performance obligation. That's what step two is about. It’s about identifying what is delivering value to our customers. So, we have these four different performance obligations that are delivering value to our customers.
Step three is: determine the total price for our revenue contract. This is a nice, easy one. We just take all the revenue values and we add them up. So, we know what our total revenue contract value is.
Step four is the exciting one that we showed before. We have the standalone selling price, which we're using to do our revenue allocation. We can see here these three performance obligations have been sold at the list price if you like. But this third one here is the one that's been discounted. So we have our standalone selling price here, and this is used in our allocation calculation. These two performance obligations have the same standalone selling price, and you can see that they have the same allocated revenue. To help my demo be nice and easy, I have made the standalone selling price of this performance obligation match this one. We can see that the revenue allocation process has allocated the same revenue to both of these performance obligations.
So, when it comes to recognizing our revenue, and we're using the allocated revenue now to drive our revenue recognition, we're going to choose our revenue recognition methods for our performance obligation, and that will drive our revenue schedules. We can see here the different performance obligations we have in this revenue contract. I'll just open for you all so we can see a little bit more of it, so we can see it's not just one performance obligation. We can see the view of how we are recognizing revenue across the different periods for the different performance obligations in that contract. This is step five of the five-step model: doing our actual revenue recognition.
So, there you can see we've had that run through with 606 and how the FinancialForce Revenue Management solutions help us with each of the five steps in the ASC 606 model.
So, now moving on to the road map slide. Obviously, we've been investing heavily in the product. We continue to do so. So, the revenue schedules that I've shown you, is available in full. That's a beta product at the moment. So it works with the subscription Billing Contracts and the revenue contracts. We're looking in the spring 2021 release to enhance our revenue schedules, and so it covers extra revenue streams, and also enhances the automation for the creation of our revenue schedules.
Lightning, you may have noticed, the demo of revenue management is fully sitting within the Lightning platform. So, that's available. If you want to move to Lightning, you will have all the the capability of the Lightning platform available to you. In the revenue management workspace we saw, again, that giving that extra support the revenue manager.
In terms of spring as well as enhancing revenue schedules, we are going to be building on the end. On the back of the revenue schedules, we’re going to be building the revenue waterfall for using Einstein. So it's really extending that capability and building on the power available within Einstein to provide additional capabilities within the revenue management space.
We're also looking, as I think one of the other sessions may cover, to provide additional support for currencies which don't have two decimal places. So, if you’re Japanese yen, for example, we are extending it so that we will be able to support those zero decimal places, or, indeed, three should you be using three decimal places.
So, just a couple of other items. So, we have revenue schedules, as I’ve already mentioned, is very much part of the product we’re investing in. If you’d like to get involved with this, do let us know, and we can help work with you on the revenue schedules feature.
A couple of other items for any partners or existing users of Revenue Management you might want to know about. So, one of the additional things we’ve delivered for fall is enhancing the summarization capability of the product. Now, it’s much more flexible, and you can choose how you summarize your revenue recognition transaction lines based on a fieldset. So, you can have - I’m not sure I would say unlimited - but it’s driven by a fieldset. So, it’s certainly up to five (at least) fields that you can configure how you summarize revenue transactions, rather than just using that cost center field, which is something we’ve done in the past. So, that’s a real improvement there.
We’ve enhanced the process of creating journals from revenue management so that we can create journals from revenue management summaries.
So, that said, we’re towards the end of the session. I hope you found that revenue management overview useful and interesting. If you would like to get in touch, if you’ve got any questions, do get in touch.
Richa: There are a couple of questions. I’ve been answering some of them, but I do want to bring these couple of them up. A couple of them are around exchange rates. So, how does revenue recognition work with currency exchange rates over a period of time? This might be a good one to address. Then, there is a follow-up.
The response to this is revenue recognition, revenue management, would accept exchange rates from the source documents. So, it can be a Billing Central contract or any other source. As long as they’re there on the source document, revenue recognition can pick those up and create RRPs from there.
There is training available on this, on communities. So, if you cannot find it, I will definitely ping one of us, and we can point you to it. This was Fall 2018, Spring 2019 feature. So, I would recommend looking at that.
Then, a related question - and this I have not answered. Is there any plan to allow multiple currencies on a sole revenue contract? We use SCM order line items as our source record to update the performance obligations and have the need for our cost to be in one currency, and our revenue in another.
I do feel that with this one, we need a follow-up discussion.
Jocasta: I think we do. Yeah. I mean, that's an interesting scenario, so it would be really good to catch up on the details behind that. Absolutely.
Richa: That would be a good one for us to follow up with you on.
The recording of this session will be available on Communities, so please look at that.
There was one more question around recognizing all performance issues. So, it should work. We have a benchmark, performed it with a sizable amount of data. So, it may be about tweaking your particular environment. I would definitely log a support case with that one, and we’ll work with our support team to see what the issues are and how we can make it work.
Jocasta: Just in case that’s been asked by somebody who has experienced issues with that, we have just recently released a service pack that has provided a few enhancements to the recognizable functionality. So, there is scope for some improvement there with the service part. But, yeah, do get in touch in terms of raising a case. We want to hear any issues you have, particularly around the recognition. We’d really like to hear about that so that we can address it.
Richa: Yeah. A couple of other questions around the workspace that you showed. It shows a rebuild of KPIs and reports. So, does it support custom reports and alerts? Can customers create those and add them to the workspace?
The answer is yes. You can create custom reports. What your customer’s showing was one that we have created and included in the workspace, but you can create your own alerts and reports. That’s been supported through summer. She also showed a deferred revenue reconciliation, which is an Einstein report, but that can also be embedded into the revenue management workspace. So, all three of those things are possible. Yeah. We would love to hear feedback on that as well.
The last question that I’m seeing is around Lightning. There has been a lot of discussion around Lightning. So, is there an impact on revenue management? Does it need an upgrade in the fall, or will Pages Classic and other Pages still work? That was raised a couple of times, this question. So, I think it’s good to address it.
The answer is while most of autumn has been converted and being converted to Lightning, all new feature functions and enhancements will come in on the Lightning pages. But the current - whwhether it’s Classic or other types - those are deprecated. So, you can continue using those. Going forward, the goal is to not have any new… There isn’t going to be any new functionality on the Visual First pages. It’s all going to be Lightning. So, it’s really a good time to start thinking of an upgrade, because, eventually, these other pages are going to be deprecated, and everything new will be available on Lightning.
I think that’s it. If there are any other questions, please go ahead and type it. We have just one more minute. Otherwise, this will be posted, and we’ll answer all the other questions online.
So, with that, thank you. I think we’re done.
Jocasta: Yup. Do join us in two weeks. There’s still time to register for the next three days that we have in place. So, there will be more and more demos, more sessions, and then other opportunities for you guys to learn more about the FinancialForce suite. So, do join us then. It would be great to see you.