Core Facility Management Software: Instrument Scheduling and Recharge Billing That Survives a Rate Study

Why core facility billing is a federal cost accounting problem wearing a booking calendar

A postdoc books the confocal for 2am on a Saturday, runs it for three hours, and the charge lands on a grant that ended on 31 December. Nobody catches it for six weeks. When the grant accountant finds it, the charge has to move, and a cost transfer of a two month old charge onto another federal award is exactly the transaction an auditor circles. Meanwhile the core director is preparing the annual rate study and discovers that instrument shows 1,240 billed hours against a log file that says 1,690, because walk up users were never recorded and afterhours sessions were entered by hand on Monday.

That gap is the entire problem. A core facility looks like a booking system from the outside. From the inside it is a federally regulated service centre where rates must be built from actual cost, charged consistently, and reconciled so the core neither profits nor accumulates an unexplained deficit. Under the Uniform Guidance cost principles at 2 CFR 200, a federally funded user cannot be charged more than an internal user for the same service, and your rates need to be defensible from cost data rather than from what the market will bear.

The products here are Agilent iLab, Stratocore PPMS and CORES. iLab is the most widely deployed in North American academic institutions and does real work on scheduling and billing. PPMS is strong on the usage capture side and popular in Europe. What all three share is that they were built to a general model of a core facility, and your institution's rate structure, subsidy allocation, chart of accounts and instrument interfaces are not general. So the core director keeps a spreadsheet, and that spreadsheet becomes the actual rate model.

Problem 1: booking is easy, entitlement is the hard part

Anyone can build a calendar. What a core actually needs to enforce is whether this specific person may book this specific instrument at this specific time. That depends on whether they completed training on that instrument, whether their training has lapsed, whether they are certified for unsupervised afterhours use, whether their lab has an active account with a valid chartfield, whether the instrument is under maintenance, and whether the booking window rules for that instrument allow a five hour block on a weekday afternoon when demand is high.

What a custom build does: model access as a computed entitlement per person per instrument, derived from training records with expiry, certification level, account status and the instrument's own policy. The booking screen shows what the person may book, not everything with a greyed out error. Refresher requirements trigger from inactivity automatically. And because the entitlement is computed rather than assigned, revoking access when someone leaves a lab is a consequence of the HR (Human Resources) or account change rather than an administrative task somebody has to remember.

Problem 2: booked time and actual time are different numbers, and you bill the wrong one

A user books three hours and runs for ninety minutes. Another walks up to a shared bench instrument and uses it without booking at all. A third starts a long acquisition that overruns into the next slot. If you bill booked time you overcharge and users learn to book short and overrun. If you bill actual time you need to know it, which means reading something the instrument produced.

This is where instrument interfaces become the real engineering work. Some instruments write log files with session start and stop. Some sit behind vendor software with a database you can query. Some have nothing, and the practical answer is a networked interlock or a card reader at the bench that gates power or login and produces a session record. PPMS is genuinely good here and worth studying. The reason a custom build often still wins is that your instrument mix is yours, and the two or three instruments generating most of your revenue are usually the ones with the most awkward interfaces.

What a custom build does: define a session as a first class object with a booked window, an actual window and a source, so every charge shows where its time came from. Reconciliation runs automatically and flags the cases that matter: sessions with no booking, bookings with no session, and overruns beyond a tolerance. Your billing policy then applies deliberately, for instance charging actual time with a minimum, or charging booked time when a no show was not cancelled inside the cancellation window. That last rule is the one that changes user behaviour, and it only works if the data is defensible enough that you are willing to enforce it.

Problem 3: rates, subsidies and the non-discrimination rule

Your rate for an instrument should come from its actual cost: service contracts, consumables, a share of staff time, and depreciation where allowable, spread over projected usage. Federal cost principles restrict which costs can enter the rate and require that a federal user is not charged more than an internal user for the same service. Institutional subsidy, which most cores need in order to keep rates survivable, has to be applied in a way that does not create a discriminatory rate.

What a custom build does: hold the rate model itself, with cost pools, allocation bases, projected volumes and the resulting rate, versioned with effective dates. Every charge records the rate version applied. External and commercial rates sit on top of the internal rate as a documented markup rather than as a separate number typed in. Subsidy is modelled as a subsidy against a known full rate rather than as a lower rate, which is both the defensible treatment and the one that lets you report on what the subsidy actually cost the institution. Then the annual rate study is a report rather than a project, and the break even position with carryforward is visible monthly instead of being discovered in June.

Problem 4: charging a grant account is a validation problem nobody automates

The charge has to land somewhere: a chartfield, a project, a grant account with a start and end date and a remaining balance. Awards end. Balances run out. A PI has eleven accounts and a student picks the wrong one from a dropdown. The core does not know any of this because account validity lives in the finance ERP (Enterprise Resource Planning).

What a custom build does: validate the account at three moments, not one. At booking, so the user cannot reserve time against an account that will have expired by the session date. At session start, because awards end between booking and use. And at charge generation, as a final check. Where a balance check is available, warn the PI and the core when remaining funds fall below a threshold rather than after the charge bounces. Give the PI a self service view of who in their lab is spending against which account, since the most common source of a wrong chartfield is a student guessing. This one feature eliminates most of the cost transfers, and cost transfers are what create audit exposure.

Problem 5: half your revenue is service work, not self service booking

Genomics, proteomics, histology and imaging analysis cores do not primarily sell instrument time. They sell a service: a sample arrives, staff run it, data comes back. That is a request with a sample manifest, a quote, a queue, staff assignment, quality control, data delivery and an invoice that may bundle instrument time, staff hours and consumables at different rates.

What a custom build does: treat the service request as its own object with a sample manifest, a defined workflow per service type, staff assignment with time capture, quality control checkpoints that can send a sample back a step, and data delivery with a link and an expiry. Charges assemble from components: instrument time from the session, staff time from the assignment, consumables from what was consumed, each at its own rate. The user sees status without emailing the core director, which is the request that consumes more of a core director's day than any other.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the honest shape for core facility software is this. A first release covering computed entitlement and booking, session capture from your two or three highest revenue instruments, rate driven charge generation and grant account validation runs $60,000 to $130,000 and ships in 10 to 16 weeks. A full platform adding the rate model with cost pools and versioning, service request workflows with sample tracking, subsidy modelling, external and commercial billing and rate study reporting runs $150,000 to $380,000 phased over 6 to 12 months.

What drives price up specifically: instrument interfaces, because every proprietary vendor software package is its own small integration project and some require a hardware interlock at the bench instead. The number of distinct cores, since a genomics core and an imaging core have almost nothing in common operationally. Integration with the finance ERP for account validation and charge posting, which is the largest single line at most institutions. External and commercial clients, because that brings invoicing, tax handling and contracts. And whether your cores currently have documented rate derivations, since reconstructing them is discovery work.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you run one or two cores with a handful of instruments and under roughly $500,000 in annual recharge. iLab or PPMS will serve you and the integration effort of a custom build will not pay back. Institutions in this position should spend on a rate study consultant rather than on software.

Build when two or more of these are true. First, your booked time and actual time differ enough that unbilled usage is a known but unmeasured number. Second, cost transfers to correct core charges are a regular occurrence, which means account validation is happening after the fact. Third, your rate derivations live in spreadsheets outside any system. Fourth, service request work is a large share of revenue and runs on email. Fifth, you operate cores across more than one campus or with an affiliated hospital, where chart of accounts and rate policy diverge.

Our position: the booking calendar is the least valuable part of this system and the part every vendor demonstrates first. The value is in entitlement, session truth, account validation and rate derivation. If a demo spends twenty minutes on the calendar and two minutes on how a charge is validated against an expired award, you are watching the wrong product.

How to choose a developer for core facility software

Ask them how they will capture actual usage on your three most awkward instruments. A credible answer names the specific instrument software, the log or database it exposes, and the fallback of a bench level interlock or reader where nothing is exposed. A developer who assumes users will record their own session times has not worked in a core.

Ask how a charge gets validated against a grant account that expires between booking and use. If validation happens only at charge generation, you will still be doing cost transfers, and cost transfers are the audit exposure you were trying to remove.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the code is yours from the first commit. Recharge records support federal cost accounting for years, and they should never depend on a vendor relationship staying friendly.