Author: Richard Clayton, HE Practice Lead, Namos Solutions
Thank you for reading part 2 of this three part blog series on Oracle Finance implementations in Higher Education.
In part 1 we discussed all things General Ledger… there was even poetry. I’m afraid this blog is devoid of poetry, although it does include a rather lovely Churchill quote!
Let’s face it, it would be difficult to take away an academics access to their favoured Purchasing Portal. Whilst it would be easy to to just set up access to Amazon as a B2B link, they are unlikely to have quite as many electronic parts as RS Online or as much lab equipment as Science Warehouse.
Customers should identify all of their Purchasing Portals upfront. What you are hoping to find is that they support B2B links (through cXML ideally). List these upfront to your implementer. They can be tricky to set up and involve some back and forth. It is better to place these in scope rather than see a change request later.
Consider if it may actually make sense to just set up eCatalogues within Oracle. It might not be quite as integrated, however, your users will still be able to make streamlined purchases.
Finally, consider configuring Smart forms to template the remainder of ordering as much as possible. These Smartforms can provide an additional layer of governance, control and standardisation making the process of purchasing quicker and more consistent than raising standard non-catalogue requests.
We know that there can be dozens of layers of governance in HE who may need to approve expenditure. Consider a £1m purchase of technology that detects hazardous materials in a building.
- The requisitioner who raises the order may need line manager approval…
- who in turn needs budget centre approval.
- The category may mean IT need to approve the technology spend or perhaps H&S and Estates…
- not to mention whatever layers of Exec level approval is required given the value.
- Buyers might need approval to raise the order.
- Then at the point of supplier invoicing there could be holds applied that require approval to release.
- Typically the requisitioner would need to receipt (see later three way match section)…
- before a payables manager approves the payment run.
This in turn could also create an asset that may have additional steps to manage.
The above example may be relevant for something of that nature, however, you need those examples to be the exception and not the norm!
You should have existing documentation on your approval rules in Standard Operating Procedures. Map out those approval rules on paper before you are paying for Oracle licences. Consider an early Discovery phase with consultants to explain what is achievable in (BPM) workflow. Know that there are force approval options, purchasing agreements, supervisory hierarchy options, delegate and reassign options, first past the post approval logic, and reports and notifications that can inform rather than request approval.
As a rule of thumb, if you can’t draw it on a reasonably sized whiteboard, whilst your implementer can systematise it, you will struggle to live with it. If you’re still struggling to convince stakeholders, quote some Churchill at them!
Out of intense complexities, intense simplicities emerge.
Payment Runs (Process Requests)
As per the above point on Approval Rules, having a deep understanding of your current Standard Operating Procedures is enormously helpful. If your implementers know up-front how and when you perform payment runs, they can advise on how to logically segregate and schedule the payment process requests.
A key piece of preliminary work is to understand with your bank the exact payment file specification and validations, particularly if paying overseas suppliers and students. If the bank needs certain information for a customer output in the payment file, you want to know in advance and ensure this is captured (and Data Migrated), especially if the source of data is a student record system rather than financial system. The logic between banks for validating/mandatory fields can be different, so knowing the requirement in advance can save time and rework.
It is typical for HE organisations to want to split out Employee Expenses runs, Supplier Payments, and Student Payments (Bursaries et al) for both UK and Overseas. In each case, splitting by Paygroups, currencies and supplier types is the most straightforward.
Three way Match
I know ‘No PO, No Pay’ isn’t always achievable in HE, especially when an Academic wants to spend the last of their research budget by tomorrow. However, set expectations with Finance Business Partners across your University that this will soon be the norm… blame the system if you have to!
Whilst this blog focusses on technology, the challenge here is one of Change Management and cultural shift. With Oracle, I would have to be convinced why in a HE organisation you wouldn’t strive for self-service procurement. You should aim to decentralise the admin effort of requisitioning, but with orders raised centrally by buyers. Opt for auto-invoice matched by Oracle Intelligent Document Recognition with suppliers quoting PO numbers. Try to avoid blanket custom holds on invoices, however, consider supplier level holds where appropriate. Set the match basis to three way, and ensure orders are receipted by requistioners (or Stores managers)… there is a standard nagging reminder you can schedule if they don’t! I appreciate this may Utopian and I appreciate we all want to avoid late supplier payments (especially as a supplier myself!). However, the move to the cloud is a chance to drive these best practices.
Payments to Students
Depending on whether you want to show Bursaries and Fees together on a single statement, or whether you need to link the Student Customer record to a Student Payment Record, a payment to a student for Bursary reasons could be as simple as a one-time-payment to a party all done within Payables. Depending on volumes, this can all be done within Oracle, file based loaders, or integrations from your Student Records System.
That being said, consider the following:
- Where a payment benefits a student but actually goes to a third party, e.g. accessibility funding etc., consider setting up third party relationships and remit the invoice to that third party supplier. Try to avoid setting up sites at supplier level that actually reflect a third party, otherwise if the third party supplier changes, you will have to change every corresponding site.
- Ensure Student suppliers have a distinct supplier type, and their invoices have a distinct paygroup. This will make it easier to pay to and report on.
- Invest in the preliminary work on rationalising business processes, e.g. how do you make sure only cash payments go to AP and not those that are to be offset against tuition fee?
- Who are the stakeholders outside of Finance? It is typical that there are different stakeholders for accessibility funds, institutional awards, local faculty/department awards, etc.
In the last in this series I will look Order to Cash and Tax. However, if you want to discuss anything raised in these blog pieces, or discuss what you might want me to cover next, feel free to get in touch!
About Namos Solutions
Namos Solutions are an award-winning Oracle OPN Modernised Partner specialising in the implementation and support of ERP, EPM and HCM business solutions, both in the Cloud and on-premise.
Although based in central London, we work wherever our clients need us to be. Many leading organisations located all over the world trust and rely on our expertise to deliver industry-leading business solutions. Namos customers can currently be found in the UK, Europe, Middle East, Asia Pacific, North America and Africa.