Procurement

Yes. It is up to teams and departments whether they want to adopt self-service or delegate it to administrators. If an administrator raises a requisition, they can still assign someone else to receipt it. 

The approvals hierarchy is being streamlined and consistent approval limits will be applied across the university. The number of approvers per Purchase Order will be significantly reduced, and approvers will receive guidance on their specific values and responsibilities. 

Departments were asked to nominate approvers earlier this year; this will be reviewed again before go live. Virtual Credit Card Purchase Orders will follow the same approvals process as any other Purchase Order. 

The system will flag a warning if spend is to exceed budget when creating a requisition however, it will not prevent a requisition from proceeding. Hard controls are not possible at this stage due to differences in how budgets are set across the organisation. 

The F-code set up is acknowledged and was the reason a hard stop could not be applied universally. This will be reviewed further as budgeting approaches are standardised.

Requisitions can be coded to any cost centre at point of requisition. This means that requisitioners will need to be aware of which codes they need to use. Individuals will be set with a default code but may need to change this. Appropriate training for requisitioners and approvers will be provided.

Approvals will be driven by cost centre, so split-coded orders will require approval from each relevant cost centre owner. 

Open Purchase Orders will be migrated to Atlas, however the preference is to minimise the number brought over. There will be some data cleansing activity before this happens.

Best practice is to raise a new service order each year rather than perpetually topping up old ones. This is something we are looking to strengthen as we transition to Atlas.

Migrated purchase orders will not be able to be amended or topped up once in Atlas.

Further communication on the migration approach will follow. Amendments to cost centres on existing Purchase Orders are much easier in Atlas than in ICIS. 

Closed Purchase Orders that are not migrated to Atlas, remain in the read-only ICIS archive for authorised users.

That is the intention. Corrupted or legacy Purchase Orders should not be migrated to Atlas.

The programme team is actively working through data cleansing to avoid bringing problems from ICIS into the new system. For any current unresolvable Purchase Orders/projects in ICIS, please contact the relevant support teams (ASK, Grants Admin, PO/AP Help).

Yes, Purchase Order value reductions will be possible in Atlas. 

Yes, an updated PDF Purchase Order will be issued to the supplier whenever an amendment is made. 

Category codes will be searchable within Atlas. They will also be shared ahead of go-live. The changes to codes are minor - mainly the addition of two new consultant-specific codes and removal of a few defunct ones. 

VAT treatment is determined by a combination of: supplier record, category code selected and intended use - the same as in ICIS. Additional fields exist for qualifying medical equipment exemptions. Calculated VAT cannot be manually overridden; any queries on a calculation should be raised with the Procurement & Tax team. 

Purchase Order transmission can be overridden at the supplier level for all orders to that supplier, but not at an individual order level. As Imperial Procurement Regulations requires that no Contractor shall be given authorisation to proceed in providing goods or services without a Purchase Order number, there should be no reason for a supplier not to receive a Purchase Order.

For travel providers such as Egencia (or a future travel management company), a universal suppression of Purchase Order transmission to that supplier can be configured. 

The process for adding delivery addresses is under review. The policy for direct deliveries to home addresses specifically is also being considered. An update will be provided. 

We've introduced goods receipting as we're implementing three-way matching, where every payment is verified against the original order, confirmation of receipt, and the supplier's invoice. This is industry best practice and it means Imperial only pays for what was ordered and actually received, protecting budgets from incorrect, duplicate, or fraudulent invoices and ensuring suppliers get paid accurately and on time.

The new receipting process is easy to do in the system, and also replaces the currently complex and manual approval process for invoices over £10k in value. 

Receipting works in the same way regardless of payment method. A Virtual Credit Card is simply a method of payment - the goods or services still need to be confirmed as received before reconciliation of the Virtual Credit Card statement is finalised. 

Yes. People who work in goods-in and departmental administrator roles will be able to receipt on behalf of someone else. Department administrators will have the option of assigning a requestor at the point of requisition. This requestor would then be responsible for receipting the goods or services. If the administrator does not assign a requestor, they will need to receipt themselves. This enables department administrators to have the flexibility over who and where they may want to delegate, or not.

The programme team will work with departments to identify who the relevant department administrators are.

For service orders (e.g. a consultant invoicing monthly against a larger Purchase Order), the value of services provided is receipted to match the invoice amount. For example, if a £40,000 Purchase Order has a £3,000 invoice, the requester receipts £3,000, releasing that invoice for payment while leaving the remaining balance open.

Yes, advance payments remain possible. The Purchase Order should be raised for the full contract value as a service order. When the deposit invoice arrives, the requester receipts the deposit amount, which releases that payment. The full Purchase Order number remains available for the supplier to invoice the final balance against. 

For a flat-fee service order, receipting is straightforward: once the service has been carried out, receipt the full amount. For a non-VAT registered supplier, the equivalent of the existing RZ/RZE category codes will be available for the new consultancy codes. 

Yes, Atlas provides better visibility of transactions, including invoice status. As a requisitioner, you will also receive a notification when a Purchase Order is matched to an invoice and a reminder prompt if receipting has not yet been completed. 

Yes, existing suppliers will be migrated from ICIS to Atlas. They will not need to be set up again. There will be some cleansing activity on suppliers that have not been used for a while.

Yes, if departmental users want to use a new supplier, they can send the supplier a link to the new Supplier Portal. Suppliers will self-populate their details via the Supplier Portal and then Procurement will be able to continue the set-up.

Much of the supplier-side data entry will become the supplier's responsibility including changes to their details.

Yes, external consultants will go through the same supplier set-up process on Atlas. The consultancy agreement process remains the same - the Purchase Order is raised as usual and the agreement attached. 

Atlas does not support supplier aliases. The legal name must be held. However, 'trading as' names can be reviewed as part of data cleansing. The search function will only return a 'trading as' name if it has been recorded in the supplier name field. 

Staff will not have access to the Supplier Portal itself, but the information on orders, invoices and payment status will be available to view within Atlas. This will be covered in future training materials. 

Yes,  many suppliers will still receive email orders. There is no expectation for all suppliers to collect their orders via the portal. Purchase Order transmission can also be overridden at supplier level (e.g. for Egencia/travel providers). 

Non-standard payment terms are set on the supplier record at set-up or as part of the contract. Any change requires authorisation from the Head of Procurement. 

Early payment requests are expected to remain off system with Accounts Payable and Procurement as they represent a variation of standard terms. The aim is that process efficiencies in Accounts Payable will make them quicker to action.