Revenue Recognition via API for Sage Intacct Journal Entries

Now, Sage Intacct does offer an add-on module for Revenue Recognition, but we’ve found that it doesn’t often work for clients in the way they expect it to. Depending on different settings, an AR invoice might be broken up into smaller daily amounts and spread over 30 days. Or, revenue recognition only is posted at the end of the day, end of the month.

If you’re looking for a precise way to handle revenue recognition in Sage Intacct, using automated journal entries might be a good way to go. We’ve created a robust, auditable system that allows you to use a rev rec date, and handle the process of moving funds from deferred revenue into the specific accrued revenue accounts – down to individual chargelines.

The process we built uses an external database (data warehouse) system to identify the specific revenue recognition date, and creates journal entries to handle the process. It adheres to GAAP and each transaction can be fully traced.

Revenue Recognition Background:
But before I delve into the specifics of how to do this in Sage Intacct via the API and sending in XML, let me explain a bit more about revenue recognition.

The typical example for revenue recognition is a magazine subscription. Let’s say that you as an end user sign up for a one year (12 month) subscription to a magazine, and the price is $24.00 for the year.

That means that each issue costs you – the end user – $2.00. But you pay the $24.00 up front, before you’ve received anything.

In this case, the company receives $24.00 in revenue.

Click for Screenshot – Revenue Recognition – Each Month as Magazine Released

But do they recognize this revenue right away? If they do (based on cash-based accounting) then they are on the hook to pay taxes on the entire $24.00 of income, less the cost of producing it. Let’s say that each issue costs $1, so over the course of the year it would be $12 of net profit.

Let’s say for round numbers that taxes are 35% of the revenue – expenses. (I know this ignores a lot of other variables, but I want to keep things as simple as possible for this example.)

If the company “recognizes” all $24.00 (revenue) – $12.00 (costs) = $12.00 net profit as soon as it’s received, then they have to pay 30% x $12.00 = $3.60.

Not a really huge deal if it’s just one transaction. But if you’re in business, it’s going to be very difficult to survive and make any money if you only have a single subscriber.

Click for Screenshot – Revenue Recognition – Individual Subscriber

If you scale it up to 10,000 subscribers, then using a non-accrual method for accounting would mean that the company would be responsible for $36,000.00 in taxes as soon as they receive the $24 subscription for all 10,000 people. Scale this up to 100,000 subscribers, and you owe $360,000.00 right away.

Click for Screenshot – Non-Revenue Recognition – Pay All At Once

Instead, if you “defer” the revenue into a deferred revenue account, you don’t have to incur quite as much tax liability.

So let’s say that for our magazine example, the end user pays $24.00, and receives the first issue about a week after paying.

In this case, the $24.00 would be added into a “Deferred Revenue” account. That means that the company has $24.00 in money, but no taxes are owed yet.

One week later when the first issue is delivered, $2.00 from the $24.00 is moved over into an accrued revenue account.

At that point, the company’s tax liability for the individual subscriber is only $0.30. If we scale that up to 100,000 subscribers, then the taxes owed are only $30,000.00 – much better than having to pay 12 times more.

Then, each month as a new issue is sent out, the company only has to pay another $0.30 in taxes for the individual subscription.

Over the course of an entire year, this helps quite a bit to save in taxes.

Now not every company is in the magazine subscription business. But quite a few are in the business where you pay now for things that are delivered in the future. Or, perhaps it’s a subscription to digital content (i.e. Netflix), but perhaps they give you a discount for paying for a year in advance.

Or let’s say your company is selling a product, but it takes a month to deliver it. In that case, you might want to have a revenue recognition date 30 days after the order is placed. Or based on another metric, such as a proof of delivery (POD) date.

Or you have a contract that is paid up front, but has deliverables that are given to the customer every 30 days.

In this case, you can use a revenue recognition date to drive deferred revenue, and then move it over to an accrued revenue account according to the business rules you set up.

Now if your needs are super simple, then creating a revenue recognition system for Sage might be overkill or too complex.

You can always use the revenue recognition module inside Sage Intacct (but you do have to pay extra for it, and it might not meet your business needs exactly).

Instead, you can use the API system to post into Sage Intacct, and create AR invoices that go to deferred revenue accounts, and then create automated journal entries that then will move the money into an accrued account, based on a date trigger.

So let’s say that we are creating an AR invoice today (03-28-2024) but we only want to recognize the revenue next month (04-28-2024).

If we are doing this via an external system, we’d want to bring in the following information:

• Post date
• Revenue Recognition date (RevRec date)
• Charge line / item code
• Amount

From there, we’d create the initial AR Sales Order into Sage Intacct via an API post (using XML), then convert it into an AR Sales Invoice:

Click for Screenshot – Revenue Recognition for Sage Intacct – Automated Journal Entries via API / XML

At this point, we’d have the charge line go into the specific GL Account for deferred AR revenue:

Then, when the revenue recognition date occurs, we’ll then create a specific journal entry – again using the Sage Intacct API system – to move the money from one account (deferred revenue) into the other account (accrued revenue):

We’ve also done implementations where we calculate the revenue recognition date based on the client, based on specific charge lines or revenue accounts or based on other complex criteria. The trick is to have the business rules clearly defined and have a reliable way to look them up in the database.