Symitar Episys to Power BI, done for you
The build starts with the extraction decision, not the first chart: which path your Jack Henry agreement actually allows, and what it can carry. Then loan balances, deposit and share mix, net member growth and delinquency are modelled by branch from one set of definitions, refreshed daily after the core’s end-of-day batch. Fixed price from $2,500, and most builds ship in 3–5 business days.
Representative dashboard — sample data
Where Episys reporting runs out
Episys is not short of reporting. It is short of a model. Almost every credit union running the core has a library of PowerOn specfiles built up over years, each one answering the question it was written for, each one producing a page of text with headings, groups and subtotals baked into it. That output is excellent at being a report and nearly useless as a data source: the moment somebody asks for the same number split a different way, the answer is a new specfile and a place in the programmer’s queue.
So the monthly packet gets assembled by hand. One extract for loan balances, another for share balances, a third for membership, the general ledger from somewhere else, and a spreadsheet that stitches them together with lookups nobody wants to inherit. It works, until the person who owns the workbook is on holiday or the board asks what changed at one branch.
The fix is not a better specfile. It is to pull the records out once at their natural grain — members, accounts, shares, loans, transactions, branches — and rebuild them as a semantic model where every metric is defined in one place. Then the loan portfolio, the deposit mix and net member growth all answer to the same branch, the same date and the same definition of “member”.
Reports we build from Episys
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.
A scheduled PowerOn extract, a relational reporting copy such as the Episys Data Store, or SymXchange for targeted real-time reads. We establish what your Jack Henry agreement allows, whether Episys is in-house or vendor-hosted, and what any access costs — before anything is designed around it.
In Episys the account number is a container, with name records for the people on it and share and loan sub-accounts beneath. Counting containers and calling them members is the single most common reason two reports disagree. We write the definition down once and every page inherits it.
Loan balances and yield, share and certificate mix, and net member growth modelled against the same branch, date and product dimensions — so loan-to-share, growth and concentration are read off one model instead of reconciled between three extracts.
Delinquency and charge-offs are snapshots, not running totals: a loan that cures leaves no trace unless you kept the daily picture. We store the snapshot so a bucket can be read as of any month end, and vintage analysis becomes possible instead of theoretical.
Member-level data does not travel by email attachment. Each user maps to a branch or region, the model filters every visual to that scope, and the roles are tested against real accounts before go-live — with documentation of who can see what for your supervisory committee.
Balances settle in the core’s end-of-day batch, so the refresh is scheduled to run after it finishes and every page carries its as-of date. History loads incrementally rather than reloading years of account detail each night.
Through a path you already own or can enable, because Power BI ships no first-party Symitar connector and there is no supported way to point it at the Episys host and start querying. Three routes do the work in practice, and they are not interchangeable — they differ in how much history they carry, how often they can run, and who has to be involved to turn them on. Which ones are available depends on your Jack Henry agreement and on whether your Episys runs in-house or is vendor-hosted, which is the first thing we establish.
Jack Henry documents its own reporting database for Episys, the Episys Data Store (opens in new tab), under its business intelligence and financial performance line. Where a credit union already licenses it, that is normally the shortest path to a refreshing dashboard: a relational copy that Power BI can read on a schedule without asking the core to do reporting work during business hours. Where it is not in place, a well-written PowerOn extract does the same job with more moving parts.
| Path | What it is | What it carries well | Practical limits | When we choose it |
|---|---|---|---|---|
| PowerOn script extract | A specfile written in Symitar’s own scripting language, scheduled in the core to write a delimited file rather than a printed report | The standard GL, member, loan and deposit extract — any record and field the core holds, at whatever grain you write it to, using logic your team already understands | Runs on the core’s batch window, so it is a daily file rather than a live feed; output has to be written extract-shaped (one row per record, keys not labels, no subtotals) or the model inherits a report’s formatting | When there is no reporting database, when the credit union has PowerOn skills in house, or when a specific extract already runs and is trusted |
| Episys Data Store | Jack Henry’s relational reporting copy of Episys data, sold under its business intelligence and financial performance line | History and breadth: Power BI reads it over SQL through the on-premises data gateway, joins it to the general ledger and other systems, and refreshes without touching the core | Licensed separately — availability, platform and cost come from your Jack Henry account team, and its refresh cadence sets the ceiling for yours | Our first choice for a dashboard whenever it is licensed or can be, because it is the only route that makes multi-year trend cheap to refresh |
| SymXchange web services | Symitar’s service layer for programmatic access to Episys records, the route integrations use | Targeted, near-real-time reads of a specific member, share or loan record, under entitlements your credit union controls | Built for transactional request-response traffic, not bulk history — pulling years of balances through it is slow, hard on the core and not what it is for | For the narrow case where a figure genuinely has to be current rather than as of last night’s batch |
| A copy someone already landed | Episys data already replicated into SQL Server, Azure SQL, Microsoft Fabric or a third-party analytics platform by a previous project | Whatever was loaded — often more than anyone remembers, and already joinable to the ledger | Needs its lineage and freshness verified before it is trusted; stale or partial loads are common | Always our first question, because it is faster to refresh and cheaper to model than starting a new extraction |
Whichever route is chosen, the landing place matters as much as the source. We put the extract in a store your credit union owns — typically SQL Server or Azure SQL behind your own gateway — rather than inside a report file on somebody’s laptop. That is what makes the dashboard survivable when the person who built it is unavailable, and it is what lets Microsoft’s incremental refresh (opens in new tab) process only what changed each night instead of reloading years of account-level detail.
Six or seven tables, most of them small. The work is not volume, it is grain: Episys holds a relationship as an account number with name records for the people on it and share and loan sub-accounts beneath, so the same extract can be counted as accounts, as members or as products depending on what you join. Naming each table’s grain out loud, once, is what stops two pages of the same report disagreeing.
| Table | Grain | Comes from | What it answers |
|---|---|---|---|
| Member | One row per person | Name records on the account | Net member growth and attrition, products per member, joint ownership, age and tenure profile of the membership |
| Account | One row per account number | The account record | Relationships opened and closed, the branch of record, and the bridge between people and the products they hold |
| Share balance snapshot | One row per share sub-account per day or month end | Share records | Deposit and share mix, certificate maturity ladder, average balance, cost of funds inputs, dormancy |
| Loan balance snapshot | One row per loan sub-account per day or month end | Loan records | Portfolio balance and yield by loan type, concentration, delinquency bucket as of any date, charge-off and recovery |
| Transaction history | One row per posted transaction | Transaction records on shares and loans | Activity and channel behaviour, fee and dividend detail, funding and payment patterns, dormancy triggers |
| Branch | One row per branch | Branch codes, mapped to the GL cost centre | Every metric on the report, split the way the organisation chart actually runs — including region and market roll-ups maintained in one place |
| Date | One row per day | Built, not extracted | Month end, quarter end, fiscal periods and prior-year comparisons, so every trend uses the same calendar |
Two modelling choices deserve a decision rather than a default. The first is which branch a loan belongs to — the one that booked it, or the one nearest the member today. Both are defensible, they produce different scorecards, and the only wrong answer is having each report pick its own. The second is the snapshot cadence: daily snapshots make delinquency vintage analysis and mid-month trend possible but cost storage, while month-end snapshots are cheap and answer most board questions. We pick with you, and the choice goes in the documentation.
Balances in Episys settle in the core’s end-of-day processing, so a balance dashboard is a daily instrument. We schedule the refresh to run after end-of-day completes and stamp the as-of date and time on every page, because the fastest way to lose a board’s trust is for someone to read a 9am figure as if it were live. Where a number genuinely has to be current — a teller-facing lookup, a real-time limit check — that is the narrow job SymXchange exists for, and we scope it separately rather than pretending a nightly model can do it.
Because the extract lands behind your firewall, the refresh runs through Microsoft’s on-premises data gateway (opens in new tab), which we help your IT team stand up if it is not already there. From there the dataset publishes to your own Power BI workspace on a schedule that matches your batch window, and the modelling discipline 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 file someone was sent. Each user account maps to a branch or region and every visual filters to that scope automatically, while the executive team reads the consolidated view from the same report. It matters more here than on most builds: this is member-level financial data, and a spreadsheet emailed to the wrong manager is a control failure rather than an inconvenience.
We configure the roles, test them against real accounts before go-live, and document who can see what — a useful artifact when your supervisory committee or an examiner asks how member data is controlled. The mechanics, including how roles and DAX filters interact, are walked through step by step in our guide to Power BI row-level security setup.
Episys answers what the membership did. It does not answer what it cost to serve them. Branch profitability needs the general ledger mapped to the same branch dimension as the core data, which is usually a short piece of work and always a conversation about cost centres rather than a technical one. Non-interest income sits partly in the core and partly with your card processor. Loan applications and decisions live in the origination system, digital adoption in online and mobile banking, and collections activity in whatever workflow tool the department actually uses.
Staffing cost is the one people forget. If the board wants deposits per full-time equivalent or a branch cost-to-serve, that number comes from your payroll system rather than from Episys, and it joins the model on the same branch key — the shape covered on our Power BI payroll dashboard page. We name each of these sources in the scope estimate, with the ones that are in scope separated from the ones that are not, 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 Symitar build — one extraction path, the member, share and loan tables, branch and date dimensions, and a loan, deposit and growth 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 beyond the core tends to move a credit union to the second tier: general ledger reconciliation for branch profitability, card processor data for interchange, delinquency vintage analysis that needs daily snapshots rebuilt from history. 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 a cooperative with a fixed annual budget: bank the hours once, spend them as the board asks new questions. See how prepaid Flex hours work for the published tiers.
Credit unions running Symitar Episys with somewhere between two and a few dozen branches, where the management packet is assembled by hand each month and the PowerOn queue is the bottleneck. It fits CEOs and CFOs who want one set of numbers, chief lending and member experience officers who need the detail underneath them, and the one analyst who currently owns the workbook everybody depends on.
If your question is which metrics a credit union board should actually be reading — the member, branch and portfolio scorecard rather than the plumbing — start with our Power BI dashboards for credit unions page; this page is deliberately about getting the data out of Episys, and the two are built to be read together. Mortgage desk pipeline and pull-through belong on Power BI dashboards for mortgage lenders, and if that desk originates in Encompass, the field mapping is on our Encompass Power BI dashboard page.
Two things we scope explicitly rather than assume. We do not write or maintain your core processing, and we do not advise on regulatory filings — this is management reporting that supports your Call Report and examination preparation, not a replacement for either. And we work only with access your own agreement already permits: your credit union owns the credentials, grants read-only access, and can revoke it 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 the board asks new questions. See Flex pricing →
How it works
We confirm which extraction path your agreement allows — PowerOn extract, Episys Data Store, SymXchange or a copy already landed — and in parallel agree the definitions: what counts as a member, which branch owns a loan, how far back usable history goes, and what the snapshot cadence needs to be. 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 credit union owns, and rebuilds the member, account, share, loan and transaction records into a star schema with branch and date dimensions — then reconciles every total against a core report your finance team already runs.
Published to your Power BI workspace with refresh scheduled after end-of-day, incremental where history is long, row-level security so each manager sees only their branch, and documentation you keep. We maintain it from your banked hours, and you can revoke our access without touching the model.
Representative perspective
Every new board question used to mean another specfile and another two weeks. Having the records modelled once means the answer is now a slicer, and our PowerOn time goes back to the operational work it should have been doing.CFO, community credit union
Representative perspective
The membership number in the board packet and the membership number in the marketing report had never matched. Writing down that one counts people and the other counts accounts — and fixing it in one place — ended an argument older than I am in this job.Chief lending officer, multi-branch credit union
Tell us how many branches you run, which extraction paths your Jack Henry agreement allows, and what the board reads each month. 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
Power BI ships no first-party Symitar connector, so the data has to be handed to it. Three paths do that: a PowerOn script scheduled in the core to write an extract file, a relational reporting copy of Episys such as Jack Henry’s Episys Data Store queried over SQL through the on-premises data gateway, or the SymXchange web services layer for targeted real-time lookups. Which ones you can use depends on your Jack Henry agreement and on whether Episys is in-house or vendor-hosted.
For a dashboard, usually a reporting copy first and PowerOn second. A relational store lets Power BI read history on a schedule without asking the core to do reporting work. PowerOn is the dependable fallback and is often already in place. SymXchange is built for transactional, request-response integration, so it is the right tool for a real-time lookup and the wrong one for pulling years of balance history.
Almost always because one counted accounts and the other counted people. In Episys the account number is a container; the people are name records attached to it, and share and loan sub-accounts hang off it. A joint owner, a member with two account numbers after a merger, and a closed-but-not-purged account each move the number. We fix the definition once in the model rather than per report.
Daily is the honest answer for balance reporting, because Episys settles balances in its end-of-day batch. We schedule the refresh to run after that batch completes and stamp the as-of date on every page, so nobody mistakes a mid-morning figure for an intraday one. Where a genuinely live number is needed, that is the narrow case SymXchange is designed for.
Yes, through row-level security in the model rather than through which file someone was sent. Each user maps to a branch or region and every visual filters to that scope automatically, while the executive team reads the consolidated view from the same report. We configure the roles, test them against real accounts before go-live, and document who can see what.
No, and it usually shortens their queue. Operational PowerOn output — notices, file maintenance, daily work lists — stays where it belongs. What moves is the standing management reporting: the month-end packet rebuilt by hand, the board slides, the branch scorecards. Those become one refreshing model, so a new question is a slicer rather than a new specfile.
No. We are an independent US-based Power BI consultancy with no Jack Henry partnership to claim and no prebuilt connector to sell. We work with whatever access your own agreement already allows, your credit union owns the credentials, and everything we build is published into your own Power BI workspace for you to keep.
The metric side of this build — which member, branch and portfolio numbers belong in front of a board, and how they are defined — is covered on our Power BI dashboards for credit unions page, which is the companion to this one. Branch cost-to-serve and deposits per full-time equivalent pull staffing cost from payroll rather than the core, which is the shape our Power BI payroll dashboard page covers. Getting each branch manager into the same report without exposing another branch’s members is a row-level security job, walked through in Power BI row-level security setup. If the quarterly artifact for directors is the real deliverable, see Power BI dashboard for board reporting. 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.