Core Facility Management Software Problems: The 7 That Cost Real Money and How to Avoid Them

Why does the better booking calendar scope failure happen so often?

Ask a core director what they need and the answer is usually a better booking system. Ask what actually costs them money and the answer is unbilled usage, cost transfers and an annual rate study that consumes weeks. The two are not the same project, and the first one is what gets specified because it is the part everyone can picture.

A calendar is straightforward to build and it is the least valuable component of the system. What a core genuinely needs to enforce is whether this specific person may book this specific instrument at this specific time, which depends on whether they completed training on that instrument, whether the training has lapsed, whether they are certified for unsupervised out of hours use, whether their laboratory has an active account with a valid chartfield, whether the instrument is under maintenance, and whether the booking window rules allow a long block on a weekday afternoon when demand is high.

The fix is to model access as a computed entitlement per person per instrument, derived from training records with expiry, certification level, account status and instrument policy. The booking screen then shows what the person may book rather than presenting everything and rejecting them afterwards. Refresher requirements trigger from inactivity automatically, and revoking access when somebody leaves a laboratory becomes a consequence of the account change rather than an administrative task that has to be remembered.

What goes wrong when usage history and rate data are migrated?

Two data sets have to come across and both are in worse shape than the project assumes.

Rate derivations first. The rate in the current system is a number. The derivation, meaning the cost pools, the allocation basis, the projected volume and the subsidy applied, lives in a spreadsheet on a core director's machine, and often in a version whose provenance nobody can explain. Migrating the number without the derivation gives you a system that charges correctly and still cannot support next year's rate study, which was one of the reasons to build.

Usage history second. Legacy session records mix booked time and actual time without distinguishing them, contain manually entered out of hours sessions typed in on a Monday, and omit walk up usage entirely. Feeding that into a projected volume calculation understates usage for exactly the instruments where the gap is largest, which then understates the rate.

The fix is to reconstruct derivations rather than import rates. Sit with each core director, rebuild the cost pools and allocation bases explicitly, and load them as versioned rate models with effective dates so every future charge records which version applied. For history, migrate it with a source flag showing whether a session was booked, measured or manually entered, and exclude manually entered records from volume projections until measured data accumulates. Confirm the treatment of specific cost categories with your cost accounting office, since institutional practice varies.

Why do instrument and finance integrations break after launch?

Three connections carry this system and each fails differently once real users arrive.

Instrument interfaces break on variety. Some instruments write clean session logs. Some sit behind vendor software with a queryable database. Some expose nothing, and the honest answer there is a networked interlock or card reader at the bench that gates login or power and produces a session record. A project that assumes one pattern across the estate discovers during integration that its two highest earning instruments are the awkward ones, which is almost a rule.

The finance system breaks on timing. Account validity and balance live in the enterprise resource planning (ERP) system, and a nightly synchronisation is not sufficient when an award ends between a booking made in March and a session run in May. Validation has to happen at booking, at session start and again at charge generation, which means three calls with three different failure behaviours rather than one.

Charge posting breaks on reconciliation. If charges post into the finance system and nothing reconciles what posted against what was generated, a failed batch becomes revenue the core never collects and nobody notices until the year end position is short. Build the reconciliation report before the posting automation, not after.

What happens when account validation and cost accounting basis are not covered?

Two gaps produce nearly all of the audit exposure in this category.

Account validation first. A postdoc books an instrument for a Saturday and the charge lands on an award that ended in December. Nobody catches it for weeks, and correcting it requires a cost transfer with a written justification. The pattern, not the individual charge, is what a monitor reads. Validating at booking, at session start and at charge generation removes most of these, and where the finance system exposes balances, warning the principal investigator and the core before funds run out removes most of the rest. Give principal investigators a self service view of who in their laboratory is spending against which account, because the most common cause of a wrong chartfield is a student guessing from a dropdown.

Cost accounting basis second. 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 rates should be built from actual cost rather than from what the market will bear. Institutional subsidy, which most cores need to keep rates survivable, has to be applied so that it does not create a discriminatory rate.

The fix is to model subsidy as a subsidy against a documented full rate rather than as a separate lower rate, and to place external and commercial rates on top of the internal rate as a defined markup rather than as unrelated numbers. Every charge records the rate version applied. The annual rate study then becomes a report, and the break even position with carryforward is visible monthly instead of being discovered in June.

Should you build custom or configure what you already own?

Many institutions should not build. With one or two cores, a handful of instruments and under roughly $500,000 in annual recharge, Agilent iLab or Stratocore PPMS will serve you and the integration effort of a custom build will not pay back. Money at that scale returns better through a rate study consultant than through software. iLab is the most widely deployed option across North American academic institutions and PPMS is genuinely strong on usage capture, which is the hardest part of the job.

Configuring what you own is also right when the real complaint is reporting. Wanting utilisation by instrument, or revenue by core, or a break even view, is a reporting problem, and a reporting layer over the system you already run is a fraction of the cost of a replacement.

Build when two or more of these hold. Booked time and actual time differ enough that unbilled usage is a known but unmeasured number. Cost transfers to correct core charges happen regularly. Your rate derivations live entirely in spreadsheets outside any system. Service request work, meaning sample submission rather than self service booking, is a large share of revenue and runs on email. Or you operate cores across more than one campus or with an affiliated hospital, where the chart of accounts and rate policy diverge.

How do hidden costs get into the quote?

The estimate moves in a short list of predictable places.

• Instrument interfaces. Budget one to three weeks per instrument type and expect wide variance, since some expose clean logs, some need a vendor database query and some need hardware at the bench.
• Number of distinct cores. A genomics core and an imaging core have almost nothing in common operationally, so each is closer to a separate configuration than a copy.
• Finance system integration. Usually the largest single line, because account validation and charge posting both touch systems owned by another department with their own change process.
• External and commercial clients. These bring invoicing, contracts, tax handling and potentially unrelated business income considerations, which is why they usually belong in a later phase.
• Undocumented rate derivations. Reconstructing them with each core director is discovery work and it cannot be compressed by adding developers.
• Service request workflows. Sample submission needs manifests, staff assignment, quality control checkpoints and data delivery, which is a different data model from booking rather than an extension of it.

What separates a build that works from one that fails here?

The builds that work treat the session as a first class object with a booked window, an actual window and a source, so every charge can show where its time came from. Reconciliation runs automatically and flags what matters: sessions with no booking, bookings with no session, and overruns beyond tolerance. Billing policy then applies deliberately, for example actual time with a minimum, or booked time when a no show was not cancelled inside the window. That last rule changes user behaviour, and it only works when the underlying data is defensible enough that you are willing to enforce it.

The builds that fail rely on self reported time. Once users record their own sessions, the data cannot support a billing policy, a rate study or an audit response, and the system becomes an expensive calendar. The second failure pattern is validating accounts only at charge generation, which leaves the cost transfers exactly where they were.

Three tests before signing. Ask how they will capture actual usage on your three most awkward instruments, expecting named instrument software, the log or database it exposes, and a bench level interlock where nothing is exposed. Ask how a charge is validated against an award that expires between booking and use. Ask where the rate derivation lives and how a past charge is traced to the rate version that produced it. Then settle ownership of the code, infrastructure and data in writing, since recharge records support federal cost accounting for years and should not depend on a vendor relationship staying friendly.