Irish TU Supplier Invoice Allocation Across Campuses

Irish TU supplier invoice allocation is most defensible when the supplier-invoice line stays as the evidence unit. Each line should carry either a campus cost centre or an allocation key, the cross-charge journal should preserve the source-file and page reference, and the same control chain should work whether the invoice arrived as a PEPPOL eInvoice or as a PDF from a smaller supplier.

For a multi-campus Technological University in Ireland, the weak point is rarely the existence of a journal — central finance can post an inter-campus recharge. The harder question is whether the journal still points back to the exact supplier-invoice line that created the cost. A line-level file that shows vendor, invoice number, line description, campus cost centre, allocation basis, source file, page number and journal reference gives AP, management accounting and internal audit the same trail. The file has to cope with three different shapes: a Microsoft 365 licence split by headcount; laboratory consumables that arrive on one Fisher Scientific invoice but belong to different labs across campuses; a research asset bought under one grant code, located on another campus and reviewed later through both grant and asset-register evidence.

Why TU campus allocation is messy during finance-system consolidation

Ireland's Technological Universities are young institutions built from older, geographically spread Institutes of Technology. Five TUs now carry the operating inheritance of 14 pre-merger ITs across more than 18 campus locations, including legacy pairings such as CIT and IT Tralee inside MTU. TU Dublin spans city-centre and suburban campuses. Munster Technological University brings Cork and Kerry together. Atlantic Technological University stretches across the west and north-west. South East Technological University and Technological University of the Shannon carry similar multi-site realities. The finance problem follows the map: invoices may arrive locally, but the reporting entity is now the TU.

The cost-centre structure does not always move as quickly as the legal merger. A pre-merger IT may have used its own chart of accounts, naming conventions, approval paths and AP routines for years. During post-merger COA unification, central finance teams have to translate those inherited structures into an institutional view without losing the campus-level meaning that budget holders still use.

Shared-service invoice allocation in Irish higher education can feel awkward in practice. A shared IT contract, library subscription, estates service, insurance bill or professional-services invoice might be paid centrally, but the benefit is not central. It belongs across campuses, faculties, schools, projects or departments. If the allocation rule is not attached to the invoice line early, the later journal becomes a finance interpretation rather than a traceable document chain.

DFHERIS's EUR65.8m Targeted Enhancement Fund, running January 2026 to December 2028 according to the Targeted Enhancement Fund announcement, gives TUs a 36-month window in which inherited local routines and a more consolidated target model will coexist.

Supplier-invoice allocation has to work in that transition. It needs to support institution-level reporting while preserving enough campus, cost-centre, project and procurement detail for the people who still manage budgets locally. A clean line-level allocation file gives finance a control that can survive both the old structure and the future one.

Three supplier-invoice scenarios central finance needs to code

The first scenario is the single shared-service invoice. A supplier bills the TU for an institution-wide service, such as enterprise software, insurance, telecoms, cleaning, security, library content or a professional-services engagement. AP may receive one invoice and one invoice line, but management accounting still needs a defensible split. The allocation key might be staff headcount, student numbers, licence counts, square metres, agreed budget share or recorded usage. The line stays single in the supplier document, but the allocation file may create several rows from it, each with its own campus cost centre and allocation percentage.

The second scenario is a multi-line supplier invoice where the lines already belong to different campuses. Laboratory consumables, facilities parts, IT equipment and teaching materials can arrive on one vendor invoice while line one belongs to Cork, line two to Kerry, line three to a research lab and line four to a central service. Summary coding loses the useful evidence. Line-item allocation across campuses works best when each line carries its own cost centre before the recharge journal is prepared.

The third scenario is the shared asset or research-related purchase. A piece of equipment may be bought under a Research Ireland grant, held under one project code, physically located on another campus, and used by more than one research group. In that case, the finance file needs more than campus cost centre. It needs grant or project code, asset-register relevance, physical location and source-document evidence. That is the point where the allocation file starts to overlap with Research Ireland grant cost-claim invoice evidence, because the same supplier invoice may later be tested through grant substantiation rather than normal AP review.

Programme or faculty allocation keys create a related pattern. A marketing invoice for recruitment activity is not a campus recharge in the same way as a shared-services bill, but it has the same evidence logic: the cost needs to be allocated to the programme, faculty or campus that benefited from the spend. That is why CAO admissions ad-spend reconciliation per programme sits beside this workflow as a neighbouring Irish higher-ed AP problem.

MTU's Cross-Charging Pay Costs material is useful because it shows the sector already treats cross-charging as a controlled finance discipline. But pay-cost cross-charging and non-pay supplier-invoice allocation should not be treated as the same process. Payroll-side evidence rests on staff assignment, timesheets, HR or payroll records and internal cost transfers. Supplier-invoice cross-charging rests on vendor documents, invoice lines, procurement references, cost-centre coding and the journal trail.

In practice, an inter-campus recharge workflow has to distinguish three questions: who received the benefit, what basis justifies the split, and which source line proves the original cost. If those questions are answered on the allocation row, the later journal is easier to review.

PEPPOL, PDFs and OGP references should feed the same coding file

Irish public bodies have been operating in a PEPPOL eInvoicing environment since the public-sector receipt obligation came into force, but that does not mean every useful supplier invoice arrives as clean structured data. Larger suppliers may send PEPPOL UBL with invoice lines already marked in a predictable structure. Smaller suppliers, local service providers and specialist vendors may still send PDFs, scanned invoices or email attachments. The campus allocation control should not depend on which format arrived first.

The output finance needs is more important than the input format. Whether the source is PEPPOL or PDF, the review file should show one row per supplier-invoice line or one row per allocation split. Each row should carry the vendor, invoice number, invoice date, description, net amount, VAT where relevant, campus cost centre, allocation key, source file and source page or line reference. Structured eInvoices can reduce the extraction effort, but they do not remove the management-accounting decision about where the cost belongs.

For PEPPOL invoices, the source line reference may be the invoice-line identifier or the relevant structured line in the UBL file. For PDFs, it may be the page number and line description. The control point is that the reviewer can move from the allocation row back to the original supplier evidence without relying on memory. A format-agnostic file also helps when one supplier changes format during the year, or when a framework supplier sends PEPPOL invoices while a smaller local supplier sends scanned PDFs for the same campus service category.

OGP framework drawdowns add a second coding dimension. If the supplier invoice relates to an OGP framework, mini-tender or drawdown, the framework reference should travel with the line into the allocation evidence. The year-end question may not only be whether the right campus paid the right share. It may also be whether the expenditure can be grouped back to the right procurement route, RFT reference or drawdown record.

That creates dual coding. A line for equipment, consultancy or software may need campus cost centre, department or project code and procurement reference. Treating the GL code as the only meaningful value flattens the evidence. A better file keeps the finance and procurement meanings separate, so AP can post the cost, management accounting can allocate it and audit can trace the procurement basis.

Whether PEPPOL or PDF, the file structure matters more than the format. The team reviewing the file should be able to filter by campus, supplier, framework reference, project code or exception status without going back to the invoice folder for every question.

The same evidence pack feeds both AP review and HEA/C&AG-facing institutional cost reporting. Those reviews, including RGAM-related cost reporting, are not interested in spreadsheet style — they want to know whether the institution can substantiate its numbers. The same mindset appears in Springboard+ provider evidence packs for HEA returns, where the quality of the pack depends on connecting the claim back to the underlying source documents.

Choose the operating route that fits the transition stage

The manual route is a monthly AP review. Central finance flags invoices that look shared, checks the source documents, agrees the allocation with the relevant budget holders and posts the recharge journal. This works for low volume, unusual suppliers or invoices where judgement is genuinely case by case.

The ERP-rule route fits a more settled environment. Agresso/Unit4 cost-centre rules, SAP cost-allocation cycles and Oracle GL allocations can handle defined categories where the chart of accounts, campuses and allocation bases are stable. That is useful for recurring central services.

The invoice-side extraction route sits between those two. Finance extracts the supplier-invoice lines before the journal is prepared, adds the campus, cost centre, allocation key, procurement reference, source file and page number, then reviews a campus-coded Excel or CSV file before posting.

Most TUs mid-transition will use a mix — manual review for one-offs, ERP rules for stable categories, extraction for the messy middle.

This is where invoice data extraction for campus-coded AP files can be a concrete part of the workflow. Invoice Data Extraction converts PDF and image invoices into structured Excel, CSV or JSON files, supports line-item extraction, and lets the user prompt for custom columns such as campus, cost centre, allocation key and OGP framework reference. Every row in the output includes source-file and page references, so saved prompts can make recurring supplier reviews more consistent while the output stays tied back to the original documents.

The output should still be treated as finance-reviewed data, not as an automatically approved journal. A campus-coded extraction file can prepare the allocation, support review and feed an import or posting process, but finance remains responsible for the allocation basis, exception handling and reconciliation to the final journal total.

A campus allocation file should be boring to review

The best allocation file is not clever — it is predictable. For a multi-campus TU, that means one row per invoice line or allocation split, stable column names, explicit allocation basis, campus cost centre, procurement reference where relevant, source file, source page and journal reference. During post-merger COA unification, keep both legacy and unified codes where the transition requires it: legacy campus code, unified cost centre, school or department, project or grant, and the allocation key that explains the split.

Mapping tables, exception flags and review cadence need owners. Campus lists, legacy cost-centre mappings, OGP framework references and recurring allocation keys need named owners with approval routes for changes. Standardised exception flags — awaiting budget-holder confirmation, allocation key changed, procurement reference missing, grant code under review, held centrally pending decision — let the finance lead sort unresolved rows instead of reading narrative comments. Recurring shared-service invoices can be reviewed monthly by exception; research, grant-funded or capital purchases deserve closer review because the evidence may be tested outside normal AP. The extracted file should reconcile to the supplier invoice total and to the posted journal total.

A TU does not need a perfect future-state ERP design before it can improve this control. Dull is the point: when the allocation row carries the cost, basis, source and journal reference, the review can focus on judgement rather than document hunting.