Ellucian Banner to Power BI, done for you
The build starts with the route out of Banner, not the first chart: which copy of your data your licensing and IT policy actually allow, and what that copy can carry. Then enrollment and census headcount, first-to-second-year retention, credit hours produced and net tuition revenue are modelled against one set of definitions that holds still at census. Fixed price from $2,500, and most builds ship in 3–5 business days.
Representative dashboard — sample data
Where Banner reporting runs out
Banner is not short of reports. It is short of a model. Almost every institution running it has years of accumulated report definitions — Argos DataBlocks, Cognos packages, saved queries somebody wrote for a dean in 2019 — each answering the question it was written for, each producing a formatted page with its own filters and its own quiet assumptions baked in. That output is excellent at being a report and nearly useless as a data source.
So the term packet is assembled by hand. Institutional research pulls headcount, the registrar pulls credit hours, the business office pulls tuition revenue, financial aid pulls packaging, and the four numbers never quite agree — because one counted students and another counted registrations, one used census and another used today, one counted the dual-enrollment cohort and another did not. The argument is never really about Banner. It is about which definition was in force when each extract ran.
The fix is not another report request. It is to take the records out once at their natural grain — people, student terms, registrations, sections, account transactions, aid awards, ledger lines — and rebuild them as a semantic model where each measure is defined in exactly one place and census is a stored fact rather than a memory.
Reports we build from Banner
Buy a block of prepaid Flex hours and, if you’re unhappy within the first 4 hours, we refund you in full — no questions asked. Hours are deducted only for work you’ve reviewed and approved, there’s no project minimum, and your banked hours never expire.
What the build covers
Each one is agreed in the scope estimate, in writing, before an hour is spent.
The Operational Data Store, the Enterprise Data Warehouse, a read-only account on Banner itself, or Ethos for targeted reads. We establish what your licensing covers, whether Banner is self-hosted or Ellucian-hosted, and who has to approve the account — before anything is designed around it.
Enrollment is a statement about a date, not about now. We store the census picture so week two stays week two after week six has happened, and so year-over-year comparisons are made between two frozen numbers instead of between a frozen one and a moving one.
In Banner a single internal person identifier carries the applicant, the student, the employee and the donor. Counting rows without resolving that key double-counts the readmitted student and loses the alumna who now teaches. We fix the identity grain once and every page inherits it.
Headcount, credit hours, charges and discount, aid disbursed and the operating ledger modelled against the same term, college and program dimensions — so net tuition revenue per student and cost per credit hour come off one model instead of being reconciled across four extracts.
Student-level records do not travel by email attachment. Each user maps to a college, department or program, the model filters every visual to that scope, and the roles are tested against real records before go-live — with documentation of who can see what for your registrar and IT security review.
Your dashboard cannot be fresher than the copy beneath it. We schedule the refresh after the overnight load finishes, load history incrementally rather than re-reading years of registration detail each night, and stamp the as-of date on every page.
Through a copy of Banner rather than through a Banner connector, because Microsoft ships none and there is no supported way to point Power BI at the application and start querying. Banner runs on an Oracle database, so every practical route ends at the Power Query Oracle database connector (opens in new tab) reading a relational source — or at an API layer that was designed for something else. What differs between the routes is how much history they carry, how often they can run, and who has to approve them.
Ellucian’s own Banner Data Warehouse solution sheet (opens in new tab) describes the two halves of that product plainly: “an operational data store for daily operational reports and ad hoc inquiries” and “an enterprise data warehouse with point-in-time data snapshots for high-speed access and analytical processing”. Those are different tools for different questions, and knowing which one a number should come from is most of the accuracy work on a Banner build.
| Route | What it is | What it carries well | Practical limits | When we choose it |
|---|---|---|---|---|
| Banner Operational Data Store | Ellucian’s reporting copy of Banner: reporting views in plain business terms, built over composite tables that an ETL process loads from the live system | Current-state operational reporting across student, finance, financial aid, HR and advancement — readable column names, documented grain, and no load placed on the production application | Licensed and installed separately, and its own refresh schedule sets the ceiling for yours; a view is still a view, so anything needing history has to be captured | Our first choice wherever it exists, because it is the shortest path from Banner to a model somebody can maintain |
| Banner Enterprise Data Warehouse | The dimensional half of the same product — star schemas holding both current aggregates and snapshots taken at institution-specific points in time | Anything that has to be reproducible: census enrollment, cohort retention and completion, year-over-year trend measured between two frozen pictures | A second implementation to license, load and maintain; its snapshots answer the questions somebody thought to schedule | When the reporting that matters is trend and census rather than “who is enrolled right now” |
| Read-only account on Banner | A database account with select-only rights against the Banner tables themselves — SPRIDEN, SPBPERS, SGBSTDN, STVTERM and the rest | Everything, at full fidelity and with no wait for a load — including the fields no reporting view exposes and the local customisations your institution made | You inherit transactional shapes, cryptic column names and the identity key in raw form; queries land on the production instance, which is why DBAs are right to ask what you intend to run | Where there is no ODS, or for the specific fields an ODS view leaves out — always scoped, scheduled off-hours and read-only |
| Ethos Integration APIs | Ellucian’s integration layer: a common data model exposed over REST, reached by an application your institution registers, whose API key is exchanged for a short-lived access token | Targeted, current reads of a specific resource, and the cross-application integration work it was actually designed for | Request-response and paged — Ellucian’s own SDK documentation warns that fetching every page of a resource in one request risks a timeout or an out-of-memory error, which is exactly what a decade of term history would be | For the narrow case that has to be current, or where the data lives in a connected application rather than in Banner |
| A copy someone already landed | Banner data already replicated into SQL Server, Azure SQL, Microsoft Fabric or a vendor-hosted analytics environment by an earlier project | Whatever was loaded — often more than anyone remembers, and already joined to other campus systems | Needs its lineage, grain and freshness verified before it is trusted; half-finished loads from a departed analyst are common | Always our first question, because refreshing something that exists is cheaper than standing up something new |
Two connection details decide whether this works on the first attempt or the fourth. Because the source sits inside your network, the refresh runs through Microsoft’s on-premises data gateway (opens in new tab) — an enterprise gateway, not a personal one, which Microsoft now states outright is unsupported for the updated Oracle connector. And the Oracle driver itself has moved: recent versions of Power BI Desktop and the gateway ship a built-in managed provider, where older setups needed the Oracle Client for Microsoft Tools installed on the gateway machine. We check which of those your environment is on before your IT team books an afternoon for it.
Seven or eight tables, and the work is grain rather than volume. Banner holds a person once and then attaches roles, terms, curricula and transactions to that internal identifier, so the same extract counts as people, as student-terms or as registrations depending on what you join. Naming each table’s grain out loud, once, is what stops two pages of the same report disagreeing in front of a cabinet.
| Table | Grain | Comes from | What it answers |
|---|---|---|---|
| Person | One row per person | Identification and biographic records, resolved on the internal person identifier | One identity behind the applicant, student, employee and donor roles — and the demographic attributes every cohort split needs |
| Student term | One row per student per academic period per curriculum | General student records with their curriculum rows | Headcount and FTE, level, college, major and concentration, classification, full- or part-time status, admit type and cohort |
| Registration | One row per student per section per term | Registration records | Credit hours produced, course demand, drop and withdrawal behaviour, seat-level enrollment by department |
| Course section | One row per section per term | Section and schedule records | Enrollment against capacity, fill rate, modality and campus, instructor of record, low-enrolling sections before the drop deadline |
| Student account transaction | One row per charge, payment or waiver | The account charge and payment detail table | Gross and net tuition revenue, discount rate, waivers and exemptions, unpaid balances and the revenue behind a registration |
| Financial aid award | One row per student per aid year per fund | Award and disbursement records | Packaging and unmet need, institutional versus external aid, disbursed versus offered, the funded half of the discount rate |
| Operating ledger | One row per fund, organisation, account and program per period | Banner Finance operating ledger | Budget against actual by department, commitments and encumbrances, the cost side of any per-student or per-credit-hour measure |
| Term and date | One row per academic period, one row per day | Term validation records plus a built calendar | Census dates, term sequencing across summer sessions, fiscal versus academic year, and prior-year comparisons on one agreed calendar |
Three modelling choices deserve a decision rather than a default. Which term sequence counts as “next year” for retention — fall to fall, or fall to any subsequent enrollment — changes the published rate and both are defensible. Whether a student with two active curricula is one student or two decides whether college-level headcounts sum to the institutional total. And whether tuition revenue is recognised on the charge or on the payment decides whether the dashboard agrees with the business office or with the registrar. We pick these with you, and each one goes in the documentation rather than into somebody’s head.
As current as the copy underneath it, which for most institutions means last night. The ODS is kept up to date by an incremental refresh that your DBA team schedules — Ellucian’s Banner ODS solution brief (opens in new tab) lists “incremental refresh mechanisms that allow for institution defined periodic refreshing of data” among what the product provides — and no dashboard can be fresher than that load. So we schedule the Power BI refresh to run after it, and stamp the as-of date and time on every page.
On the Power BI side the same discipline applies in reverse: incremental refresh (opens in new tab) processes only the periods that changed instead of re-reading a decade of registration detail every night, which is what keeps a multi-year model refreshing inside its window during add/drop week. The modelling craft underneath is the same one described on our Power BI data modeling and DAX page.
Through row-level security in the model, not through which export somebody was emailed. Each user account maps to a college, department or program, every visual filters to that scope automatically, and the provost’s office reads the consolidated view from the same report. It matters more here than on most builds: these are student education records, and a spreadsheet forwarded to the wrong chair is a disclosure question rather than an inconvenience.
We configure the roles, test them against real records before go-live, and document who can see what — a useful artifact when your registrar, IT security review or internal audit asks how student data is controlled. Your institution remains the party responsible for FERPA obligations; our part is to make the access boundary explicit and testable rather than implied. The mechanics, including how roles and DAX filters interact, are walked through in our guide to Power BI row-level security setup.
Banner answers what happened inside the institution of record. It does not answer everything the cabinet asks. Inquiry and applicant behaviour before the admit decision usually lives in Slate or another CRM; course activity and early alerts live in Canvas, Blackboard or Moodle; giving lives in the advancement database; and faculty and staff employment may live in Banner HR or in a separate HCM tenant entirely.
Each of those joins the model on a key we agree in advance rather than on a name match. Institutions whose advancement records sit in Blackbaud will find the extraction side — application registration, rate limits, gift splits and soft credits — on our Raiser’s Edge NXT Power BI dashboard page. Institutions running Workday for employment data alongside Banner for students can reuse the same pattern for workforce reporting, covered on our Workday Power BI dashboard page. And where dual-enrollment or early-college records arrive from feeder districts, the routes out of that system are on our PowerSchool Power BI dashboard page. We name each source in the scope estimate, with in-scope separated from out-of-scope, so nothing is quietly assumed.
You buy prepaid Flex hours that never expire: Starter is 20 hours at $125/hr ($2,500), Growth is 40 hours at $115/hr ($4,600), and Power is 80 hours at $100/hr ($8,000). Hourly work starts from $100/hr. A first Banner build — one route out of the data, the person, student-term and registration tables, term and college dimensions, and an enrollment, retention and credit-hour report set — usually fits inside the Starter block, and most ship in 3–5 business days once the scope estimate is approved.
Work that reaches past the student records tends to move an institution to the second tier: net tuition revenue reconciled to the business office, aid packaging joined at fund level, operating-ledger integration for departmental budget against actual, or rebuilding several years of census snapshots that were never stored. There is no project minimum and no retainer — you refill only when you want more, and hours are deducted only for work you have reviewed and approved. That suits an institution with a fixed annual budget: bank the hours once, spend them as each term raises a new question. See how prepaid Flex hours work for the published tiers.
Colleges and universities running Ellucian Banner where the enrollment packet is rebuilt by hand each term and the reporting request queue is the bottleneck. It fits institutional research and enrollment management offices, business offices that need tuition revenue tied to registrations, deans who want their own college’s numbers without a request, and the one analyst who currently owns the workbook everybody depends on.
If your question is which metrics a college or university should be reading — the admissions funnel, retention and completion, tuition discount rate, the endowment draw — start with our Power BI dashboards for higher education page instead. That page is about what to measure; this one is deliberately about how to get the data out of Banner, and the two are built to be read together. Where the same figures have to reach trustees on a fixed cadence, the pack and period discipline is on Power BI dashboards for board reporting.
Two things we scope explicitly rather than assume. We do not administer Banner, write Banner customisations or advise on IPEDS, state or accreditor submissions — this is management reporting that supports that work, not a substitute for the offices that own it. And we work only with access your own licensing and IT policy already permit: your institution owns the credentials, grants them read-only, and can revoke them at any time without touching the model. Contact is form-only — send your request and we reply with a scope estimate.
business days, typical
fixed-price first build
own everything
Bank hours once and spend them as each term raises new questions. See Flex pricing →
How it works
We confirm which copy of Banner your licensing and IT policy allow — the ODS, the Enterprise Data Warehouse, a read-only account, Ethos, or something already landed — and in parallel agree the definitions: which census dates matter, how retention is counted, whether a double-major is one student or two, and how far back usable history really goes. You get a scope and hours estimate before any work begins.
A senior US-based engineer builds the scheduled extraction, lands it in a store your institution owns, and rebuilds the person, student-term, registration, account and aid records into a star schema with term, college and program dimensions — then reconciles every total against a report your institutional research office already trusts.
Published to your Power BI workspace with refresh scheduled after the overnight load, incremental where history is long, row-level security so each dean sees their own college, and documentation you keep. We maintain it from your banked hours, and you can revoke our access without touching the model.
Representative perspective
Every cabinet meeting started with ten minutes of arguing about whose headcount was right. Writing the definitions down once, and freezing census in the model, gave us those ten minutes back and a conversation about the trend instead.Director of institutional research, public university
Representative perspective
We could always get last night’s enrollment. What we could never get was last fall’s enrollment as it looked last fall. Having the snapshot stored changed what we could say to the board about the trend.Associate vice president of enrollment management, private college
Tell us which copy of Banner you can reach, which census dates your reporting runs on, and what the cabinet reads each term. We’ll confirm the route and the definitions, then tell you the hours before any work begins — drawn from prepaid Flex hours that never expire, with no project minimums and no obligation.
FAQ
Through a relational copy of Banner rather than through a Banner connector, because Microsoft ships none. Banner runs on Oracle, so Power BI reads it with the Oracle database connector — normally against the Banner Operational Data Store or Enterprise Data Warehouse, sometimes against a read-only account on Banner itself — over an enterprise on-premises data gateway. Ethos Integration covers the targeted, cross-application reads that a relational route cannot.
Usually the ODS first, the EDW for anything that has to hold still, and Ethos for neither. The ODS gives you reporting views in plain business terms over a copy that refreshes on your schedule. The EDW adds the point-in-time snapshot stars that make a census-date number reproducible. Ethos is a request-response API layer built for integration, not for pulling a decade of term history each night.
Because Banner is a live transactional system and the query is being re-asked of today’s data. Registrations, withdrawals, program changes and residency updates keep moving after census, so a headcount run in week six cannot reproduce the week-two figure unless somebody kept that picture. We model census as a stored snapshot, which is exactly what the Enterprise Data Warehouse snapshot stars exist to provide.
As often as the copy underneath it refreshes, which for most institutions is nightly. The ODS is kept current by an incremental refresh your DBA team schedules, and your dashboard cannot be fresher than that load — so we schedule after it, stamp the as-of date on every page, and say plainly that the number is as of last night rather than implying it is live.
Yes, through row-level security in the model rather than through which export someone was emailed. Each user maps to a college, department or program and every visual filters to that scope, while the provost and cabinet read the consolidated view from the same report. We configure the roles, test them against real records before go-live, and document who can see what for your registrar and IT security review.
No, and it usually shortens the reporting queue. Operational output — class lists, registrar worklists, letters and audit detail — stays where it belongs. What moves is the standing management reporting: the enrollment packet rebuilt by hand each term, the cabinet slides, the trustee pack. Those become one refreshing model, so the next question is a slicer rather than a new report request.
No. We are an independent US-based Power BI consultancy with no Ellucian partnership to claim and no prebuilt Banner connector to sell. We work with the access your own licensing and IT policy already allow, your institution owns the credentials and grants them read-only, and everything we build is published into a Power BI workspace you keep.
The metric side of this build — which enrollment, retention, completion and net tuition revenue figures belong in front of a cabinet, and how each is defined — is covered on our Power BI dashboards for higher education page, which is the companion to this one. Getting each dean into the same report without exposing another college’s students is a row-level security job, walked through in Power BI row-level security setup. If the quarterly artifact for trustees is the real deliverable, see Power BI dashboards for board reporting, and the modelling craft underneath all of it is on our data modeling and DAX page. Institutions replacing an ageing Cognos estate rather than reporting alongside it should start from Cognos to Power BI migration. Every task is scoped before work begins from your prepaid block of senior-led hours — no project minimums, no change-order surprises, and hours are deducted only for work you approve.
Book a free demo
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.