Which option—Accrue at Period End or Accrue at Receipt—works best for you?

A key policy decision during implementing Oracle Fusion for Receipt Accounting for Expense category PO lines is choosing between “Accrue at Receipt” or “Accrue at Period End”. In our Managed Service journey, we have seen many clients facing issues because of uninformed decisions regarding Accrue at Receipt or Period end resulting in piling up of expense accruals, inaccurate expense booking etc.

Making well-informed decisions is essential and relies on a thorough understanding of the business and expert guidance. A wrong decision here can impact the functioning of the business process and result in inaccurate financial reporting. For instance, a company misreporting just 3% on a $10 million expense budget could be presenting $300,000 in errors in a financial statement.

A wrong decision can impact the organization in following ways –

The key differences of these two Accrual concepts are as below –

  • Accrue at receipt (also known as perpetual accrual) – The Accounting entry for expense and accrual is recorded when you create Receipt in Oracle. When you create accounting for the invoice, the accrual is reversed, and the accounts payable liability is recorded.

For Inventory category PO Lines, “Accrue at Receipt” option is selected by default.

  • Accrue at period end – No accounting entry is made when a Receipt is created in Oracle for items or services and the expense is recorded only when the invoice is booked. There is no major dependency on receipt creation for booking the expense. We need to run the “Create Period End Accruals” process to create accrual journal entries for all uninvoiced receipts. The entries are automatically reversed in the next period.

Accounting entries in different scenarios:

 

Events Accrue at Receipt Accrue at Period End
PO Creation No Entry No Entry
Receipt Creation Receiving (Dr)

Accrual (Cr)

No Entry
Expense booking (Put Away) Expense (Dr)

Receiving (Cr)

No Entry
Invoice booking Accrual (Dr)

Liability (Cr)

Expense (Dr)

Liability (Cr)

Period End Accrual

(For Uninvoiced Receipts)

No Entry Expense (Dr)

Accrual (Cr)

 

Difference between Accrue at Receipt vs Period End:

 

Metrics Accrue at Receipt Accrue at Period End
Expense Accrual On Receipt Creation On Invoice Booking
Separate Accrual at month end Not Required At Month End for Uninvoiced Receipt
Inflow of Expense to Project On Receipt Accounting On Invoice Accounting
Inflow of Expense to Fixed Assets Possible on Receipt Accounting Only on Invoice Accounting
Accrual Write Off Required Not Required
Invoice Price Variance (Difference between Purchase & Invoice) Invoice Price Variance generated during invoice processing Charged directly to expense instead of Invoice Price Variance
Non-Recoverable Tax variance tracking in case of rate change Tax Variance generated during invoice processing Charged directly to tax instead of Tax Variance
Using Multi-Period Accounting (MPA) MPA not possible to be used MPA can be used for these lines
Reconciliation Report for Uninvoiced Receipt Accrual Reconciliation Report Uninvoiced Receipt Accrual Report
Budget release in case of Encumbrance accounting Funds released on Receipt creation Funds released on Invoice creation

 

In the Accrue at Receipt method, timely booking of receipts is crucial for recognizing expenses. If the organization lacks personnel to perform real-time receiving, it can disrupt the expense booking process. We have observed that organizations choosing the Accrue at Receipt option for expense items often face delays in expense recognition due to delays in creating receipts.

For example, one of the entities was following a Cost-Plus model for raising the invoices to customer from Projects Contract. But there was no dedicated user who would record the receipts resulting in inadequate costs being reported.

Key factors to consider before deciding Accrue at Receipt vs Accrue at Period End Option:

The decision needs to be taken based on the nature of the business processes and the different types of expenses. The following are the key parameters to be considered –

 

Metrics Accrue at Receipt Accrue at Period End
Company has requirement to book the expenses once goods/services are received in Oracle.

X

Company has business SOP in place for doing the receiving for all different type of goods/services.

X

Company has decentralized operations and services are received at different places. It is difficult to have users perform the receiving at different places.

X

 

 

Company does not have designated team/reasonable team size to perform the receiving within the system.

X

 

 

Company has requirement to accurately update Project Forecasts on monthly basis based on Project Cost.

X

Company has requirement of Fixed Assets to be capitalised based on accurate date placed in service i.e. receipt date.

X

 

Based on above considerations, the client should determine the business process that they need to follow considering available resources and then take a decision whether they want to go for Accrue at Receipt or Accrue at Period End.

Accrual Flexibility in Oracle – Receipt or Period End:

  1. For Expense category PO Lines, the client will have an option on the Manage Common Options for Payables and Procurement page to be set as Accrue at receipt or period end.
  2. However, the default value of Accrue at Receipt or Period end can be changed at the PO Line Schedule level based on specific requirement for that PO Line.

For example, if client has selected Accrue at receipt at the setup level but for a PO Line of Insurance expense, the user needs to have the multiperiod accounting to be created, then the user can change to Accrue at Period end for this PO Line.

Best Practices when using Period end accrual:

  1. At the end of accounting period, you must run “Create Uninvoiced Receipt Accrual” process after closing the Accounts Payable period and transferring all the Accounts Payable invoices to Cost Management, and before you close the General Ledger period.
  2. Run the Create Un invoiced Receipts Accruals process in the Report accrual run mode to review the entries before it gets posted. The report helps you to understand the details about the Uninvoiced purchase order receipts for which accruals will be created. After analysis of the report and making required updates, the process should be run in final mode.
  3. Auto Reversal of the receipt accrual entries should be set.

Best Practices when using Accrue at Receipt:

  1. In case of Accrue at Receipt, PO line should not have Invoice Match option as “Order” and Match Approval level as “2-way”. As in such case, the receipt creation might be missed and expense would be charged only if the receipt is booked, resulting in under-reporting of expenses.
  2. Accrual Reconciliation Report should be run on periodic basis and open entries should be analysed.
  3. Accrual Aging and Receiving Inspection account should be reconciled and analysed at regular intervals. Timely Accrual write-off should be done for the open Purchase orders where the Invoices are not received for the Receipts created or vice versa.

Digital Transformation: Out with the Old, In with the YOU!

Digital transformation is a pivotal change reshaping how businesses operate, utilizing digital tools to revolutionize strategies, processes, and customer experiences. It goes beyond technology adoption, fundamentally altering traditional approaches to drive innovation, efficiency, and competitiveness.

Digital Transformation activity sometimes might feel exhausting because tt involves too many people, takes far too long and by the time the project is over, users are too exhausted to celebrate the benefits.

While all this is not untrue, seldom do organizations remember why they chose to undertake this massive activity in the first place. Digital Transformations are organization’s door to the future, and users get to decide on the architectural style of it.

We tell our clients that this activity requires a mindset shift and this is why we say so –

Sweeping Away the Cobwebs of Obsolete Systems: In the world of business, some processes feel as ancient as dial-up internet. Digital transformation is the ultimate broom, sweeping away those cobweb-covered relics and introducing a fresh, streamlined approach.

Letting Go of Technological Antiques: Remember the days of floppy disks and fax machines? It’s time for them to retire to the museum of nostalgia. Embracing digital transformation means bidding adieu to these relics and welcoming cutting-edge technologies.

Revamping Business Processes: The Marie Kondo Way: Just as Marie Kondo revolutionized decluttering, digital transformation revamps business processes. It’s about discarding what doesn’t spark joy in operations and embracing tools and systems that do.

Smooth Collaboration & Heightened Efficiency: Digital tools eliminate the chaos of sticky notes and endless email threads, fostering seamless teamwork. And, with automation taking the reins, tasks are completed faster than a birthday cake vanishes at an office party.

Thriving, Not Just Surviving: Digital transformation isn’t a mere upgrade; it’s a leap toward flourishing. It’s about seizing opportunities, innovating, and staying ahead in a landscape that changes as swiftly as fashion trends.

So, let’s toast to a tech savvy, personalized future. Here’s to shedding the old skin, refining the outdated, and diving headfirst into a world of possibilities. The digital transformation journey promises a buffet of opportunities as vast as an endless brunch menu. Cheers to a fresh start in the digital realm!

Orbrick wishes you a very happy new year!

Digital Transformation through Gandhi’s Words

As Gandhi Jayanti comes to a close, we reflect upon the teachings of the Mahatma.

Mahatma Gandhi has taught the world a lot. His Experiments with Truth resulted in many learnings which he shared with the world and led by example. His life and his legacy are a rich source of lessons. Gandhi asked us to be slow in forming our convictions, but once formed defend them against all odds. Here are 3 of his quotes that reinforce our convictions about doing better Digital Transformations.

“Be the change you are trying to create.”

Probably the most famous Gandhi quote. It’s been plastered on graffitied walls, countless internet articles and motivational posters – but repetition doesn’t make anything untrue.

Many projects start with the leadership wanting to change things in their organizations. They sponsor the projects, hire a vendor, select a product, get the teams together, and then somehow leave the implementation and operation of their new tool to the teams that are key users but may or may not share their overall vision. True transformation needs both – the view that keeps the North Star or the purpose of the project in sight, and the view that keeps practical realities and details in sight. A project without active sponsorship will not usually result in the kind of change that the project sponsors hope for unless that are hands-on and participate in steering committee meetings, decision making and keep a finger on the overall pulse of the project. They have to not only be involved during the development, but perhaps even more importantly during deployment and adoption. They have to “be” the change and be the first brand ambassadors of the new tool. They should be seen using it, and involved in the process of rolling it out. They should be talking about it to their people right from the get go. This causes a lot of people to see it as a more organic change and not something sudden and unwelcome.

“There is more to life than increasing its speed.”

Speed is typically one of the main things we want from any digital transformation, right besides cost savings. This, while understandable, sometimes becomes a hindrance to getting something better. We must decide on other, and better metrics besides just speed of execution. Afterall, we are what we measure.

If we take bad business processes and digitize them to make them a whole lot faster – we have created ways to be terrible, faster. We have to descend into the details of each project, understand how we can re-engineer our processes to make them better processes, and then make the execution of those processes faster!

“My aim is not to be consistent with my previous statements on a given question, but to be consistent with truth as it may present itself to me at a given moment. The result has been that I have grown from truth to truth.”

He believed that truth is self-evident. He said truth emerges when we remove the cobwebs of Ignorance. His famous Satyagraha is simply the insistence of truth. His autobiography isn’t called “The Truth” or “My Truth”, but rather consistently with his overall believe – is called “My Experiments with Truth”.

All ERP/EPM implementations are done, at their very core, to collect data that can be reported on. The entire point of large, cross-functional systems like Oracle Fusion is that a single environment helps with cross-functional reporting. But all too often we using reporting as just that – a report to be read. What’s worse – sometimes we use it to feed our Confirmation bias. The aim of these transformations is often to support great reporting. But that reporting will only turn into value when we design for truth-prompted and data-guided actions. We at Orbrick build solutions that represent the truth of the organization we work with. Analysis, KPIs and KRAs that accurately show the reality of businesses and organizations, and not just an aggregation of data left to be interpret. We don’t lie with statistics. And we make our analytics actionable. We want our partners and customers to be able to spring into action when the truth changes from what it was a while ago.

We want to grow with them, from truth to truth!

Website launch and 3 lessons from Chandrayan-3

India, and the world at large, held its breath as the Chandrayaan-3 touched the surface of the Moon. The South side of the Moon is in our reach for the first time since man saw the white orb in the sky some 300,000 years ago.

We thought of launching our updated website (sans propogation delay) to match the date of the Chandrayaan-3 landing because there is something quite universally optimistic about uncovering the unknown.

Humanity has a history of flourishing when someone has made us “look up”. The sky has been an infinite inspiration to insatiable curiosity that has pushed the entire expanse of humanity forward. There are literal songs about going to the Dark Side of the Moon. But on 23rd August 2023, people once again looked up in unison, and aspired to be more.

We feel it is symbolically in line with our vision to help consulting as an industry “look up”. That is our moonshot.

There’s a lot that the Moon landing can teach us. Here’s the top three lessons from the mission with a direct relationship to Consulting and ERP.

Think Big

In 1969, Kennedy succeeded in putting a man on the moon. He said “We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard.” 500 million people watched the Moon landing. 6 decades later we are only the fourth country to land on the Moon’s surface, and the first to land near the lunar south pole. This is a huge deal.

I had a professor who used to tell us, “you are only as big as the biggest problem you try to solve” or “you can only be as big as the cause you champion”. Too often we get bogged down into unnecessary operational details during either implementation or enhancement phases and miss the bigger picture. This leads to over-customization, needless delays, over-shot budgets, unmet requirements etc., missing the primary purpose of the transformation project. We end up focusing on the smaller, almost irrelevant aspects of the project and getting hung up on them.

As explained by Daniel Kanheman, humans have a subconscious bias towards substituting a hard question to a simpler one and then answering that. So “do I like her idea?” becomes “do I like her?”. And “improve customer happiness” becomes “get a high rating on customer index score”. When you over-optimize for the smaller vision, you get issues such as a car service brand I know (and won’t name) which calls customer informally asking for what their rating is (before the formal call where they log the rating). If the customer gives a low rating they ask if they’ll give a higher rating against a voucher. If the customer is still inclined to give a bad rating then that customer gets spuriously dropped from the “random sample” of customers being asked for reviews! This improves the CSAT score a lot without actually contributing at all to customer satisfaction. Such things also happen in ERP implementations where instead of making the system aligned to the transformation’s vision, it gets aligned to a particular page layout or a step in a process derailing the project.

This can be avoided by agreeing on the right metrics from the get go and reflecting regularly on whether the investment is giving the right results.

Failure is the road to success

“I never lose. I either win or I learn” – Nelson Mandela

Chandrayaan-2 was a partial failure. ISRO still went ahead with Chandrayaan-3 and used all the mistakes made during Chandrayaan-2 to come out successful.

A lot of ERP implementations fail. This breeds an understandable amount of PTSD (Post Traumatic Stress) to customers who either don’t want to reinvest time with a new partner on another project, or start from a position of mistrust and pessimism. That’s not a good way to start a project. Each failure brings a valuable trove of learning which can be carried forward to all other projects. What’s important is to take failures in projects as lessons and path correct to realign to the bigger vision.

The aim has to be to not repeat mistakes. That’s why we have made significant investments in ensuring we capture and distill the learnings from our team’s previous experience from hundreds of both successful and failed implementations to put them into actionable insights.

The Part is the Whole

Each part is a partner in making the ‘whole’ function well. You can’t have a functional whole if a part malfunctions. Chandrayaan-2 didn’t fully succeed because of a failed valve and a software glitch. Chandrayaan-3 solved for those issues.

The infamous King’s Cross Fire in London is also a case study in why oversegmentation of responsibilities with no regard to how the whole is impacted may be a bad thing. The initial fire went unattended because of many organization culture abd structure issues as well.

Some of them were:

  1. There was no single person responsible for safety. It suffered from diffusion of responsibility.
  2. The organization structure was isolated, and internal communication was very strained. They didn’t even have an organization chart.
  3. Every department did their own function without much heed to how the whole thing had to function.

In the context of ERP systems, too often we see key stakeholders being left out of conversations, very little attention being paid to the net positives and how organization wide impacts are created in such transformations, compartmentalization (and therefore a lack of a big picture view) of responsibilities, and not enough work done to adopt the change. Every department and consulting team becomes bogged down in screens visible to them and don’t pay enough attention to how things impact the whole.

These issues can be addressed by keeping the purpose of the implementation front and center, looking at net positives, and having a mixed team structure that brings in all the right stakeholders. It is also important to have regular training sessions during and after implementations, and transparency in progress, outcomes and challenges to all parties.

As you take your next moonshot with Digital Tranformations, keep these 3 lessons from Chandrayaan-3 in mind and we’re sure you will land safely! And of course, if you want a trustworthy partner in your journey – please don’t hesitate to get in touch.