Bullhorn Reporting and Analytics, Beyond the Defaults
TL;DR: Bullhorn's out-of-the-box reports are reliable for placement volume and activity counts and unreliable for anything financial until you have checked what came across in migration. Canvas is a configurable report layer rather than a BI tool, so build one dashboard per audience: five or six numbers for directors, this week's activity for consultants, named lists of missing items for compliance. AWR tracking, IR35 classification and perm fee realisation all need a custom field or a workaround, because Bullhorn is a US-built product with UK requirements retrofitted. Most reporting projects fail on data quality and adoption rather than on the build, so fix duplicates, sector taxonomy and missing placement financials before you spend money on Cube19 or Power BI.
What do Bullhorn reporting and analytics give you out of the box?
Bullhorn's standard reports fall into four categories. Activity reports cover calls, notes, emails, and submissions - they pull from activity records logged against contacts, candidates, and job orders. Pipeline reports show job orders by stage, owned by which consultant, and how long they have been open. Placement reports cover volume, placement type, and owner. Financial reports pull from placement records and cover margin, revenue, fees, bill rate, and pay rate.
The first thing worth flagging: every single one of those report categories is only as accurate as the data consultants enter. Activity reports are noise the moment consultants log calls inconsistently - or do not log them at all. There is no workaround for that. It is a process problem, and it shows up immediately in the data.
There is also a field naming issue that catches UK agencies out early. Bullhorn's default field labelling was built for a North American context. "Job Type" in standard Bullhorn does not always map cleanly to how a UK agency distinguishes perm, contract, and temp - particularly once you factor in fixed-term contracts, temp-to-perm arrangements, and statement-of-work engagements. Agencies customise these fields during implementation, which is correct, but the standard report filters still reference the original field values. The result is reports that run without errors but return wrong or incomplete results. Nobody notices for weeks.
The out-of-the-box financial reports are useful for high-level revenue tracking, but they require placement records to be populated correctly. Estimated GP, actual GP, bill rate, pay rate - all of it needs to be present. Many agencies, especially those that migrated from a previous ATS within the last two years, have patchy data on historical placements. Older records frequently have missing or incorrectly mapped financial fields from the migration process.
The reports that are genuinely reliable from day one, without any configuration, are placement volume by owner, new placements this month by type, and basic activity counts per consultant. Anything financial needs checking before you trust it.
Before building any margin dashboard, I would run a spot check first. Take 20 placements from your previous system, find the corresponding records in Bullhorn, and verify that actual GP, bill rate, pay rate, and placement type all match. If more than three of those 20 have gaps or mismatches, you have a data quality problem to resolve before you have a reporting problem to solve.
How should you structure Canvas dashboards for different audiences?
Build a separate Canvas dashboard for each audience rather than one dashboard for everybody. Directors need five or six numbers: margin by division, revenue against target, fill rate, contract headcount. Consultants need this week's activity and their placements against personal target, and ops and compliance teams need named lists of specific missing items rather than a percentage score.
Canvas is Bullhorn's report builder. It is not a drag-and-drop BI tool in the way that Power BI or Looker is - it is a configurable report layer that lets you build structured dashboards against Bullhorn's data objects. Set that expectation before you start, because people who have used modern BI tools will find Canvas limited and will ask for things it cannot easily do.
The most common mistake in Canvas implementations is building one dashboard and calling it done. Different users need different things, and a dashboard built for a director is useless for a consultant and vice versa.
Directors
Directors need margin by division, revenue against target, fill rate, and headcount on contract. Five or six metrics is the ceiling - directors who receive a 20-metric dashboard look at none of them. Revenue against target requires targets to be set in the system or imported from an external source, which is a configuration step many agencies skip. If targets are not in Bullhorn, the "vs target" comparison has to happen in Excel after the fact, which defeats the purpose.
Consultants
Consultants use reports to manage today, not to analyse last quarter. What they need is: calls made this week, CVs sent this week, interviews arranged this week, placements this month against personal target. The emphasis is on the current week. Historical trend data is a management tool, not a consultant tool. A consultant report that shows 12 weeks of rolling activity data is a report the consultant will ignore after the first time they open it.
Ops and compliance teams
Compliance reports are operational, not KPI-based. The format should be a list of names and specific missing items - contractor records approaching the AWR 12-week threshold, right-to-work documents expiring within 60 days, placement records with incomplete compliance checklists. A percentage score ("82% compliance rate") is not actionable. A list of 14 contractors with the specific issue against each name is. Build these reports to be exported and acted on, not admired.
A Canvas dashboard is a tool, not a deliverable. The deliverable is the decision or action it produces. If you cannot articulate what action a specific report is supposed to drive, the report should not exist.
The UK recruitment KPIs worth tracking, and how to build them in Bullhorn
Five metrics are particularly relevant for UK staffing businesses. Here is what each one requires in Bullhorn and where each one breaks down:
CV-to-interview ratio: submissions divided by interviews arranged. Bullhorn tracks submissions natively via the candidate submission record. The interview stage has to be configured correctly in the job workflow for this metric to be calculable. If interview stages are not set up in the workflow, there is no data to divide. In tech perm recruitment, a CV-to-interview ratio of 5:1 to 8:1 is broadly typical. In volume temp, it can run tighter - 2:1 or 3:1 is not unusual. Those are indicative ranges, not benchmarks to optimise against without context.
Interview-to-placement ratio: straightforward from Bullhorn if placement records are correctly linked to the originating job order. It breaks down when consultants create standalone placement records not attached to a job order - which happens more often than it should, usually when the placement was agreed verbally and the job order was created retrospectively or not at all.
Time-to-fill by sector: calculated from job order created date to placement start date, segmented by the category or sector field. The calculation itself is simple. The problem is whether sector taxonomy is applied consistently across the team - covered in more detail in the data quality section below.
Margin by contract type: requires bill rate, pay rate, and hours (for temp and contract) or fee percentage (for perm) to be correctly entered on the placement record. This can be built in Canvas but the financial fields must be populated. Partially populated placement records drop out of margin calculations entirely - they show up in volume counts but not in any financial report.
Perm fee realisation rate: actual fee received versus fee quoted at placement. Bullhorn holds the quoted fee on the placement record. What it does not hold natively is rebates, write-offs, or instalment structures. Most agencies track realised fee in their finance system, not in Bullhorn. Building a true fee realisation report in Bullhorn almost always requires a workaround - either a custom field updated manually, or a data feed from the finance system. Do not assume this is available out of the box, because it is not.
Consultants often assume Bullhorn tracks all of this automatically. It does not. Several of these metrics require deliberate configuration, and most require consistent data entry by the consultants themselves.
UK-specific reporting considerations Bullhorn won't mention
Bullhorn is a US-built product. UK compliance requirements were retrofitted, not designed in from the start. The system can support UK-specific reporting needs, but it will not do so automatically.
AWR tracking: UK agencies placing temporary workers need to know when workers are approaching the 12-week qualifying threshold under the Agency Workers Regulations. Bullhorn holds start dates and placement records, so in theory a report can surface workers with 10 or more weeks of continuous placement at a single hirer. In practice, this calculation is fragile. Gaps in assignment records, variations in how the same hirer is named across different records ("Acme Ltd" versus "Acme Limited"), and multiple part-time placements at the same client all create errors. Native Bullhorn reporting can filter by start date, but the continuous-weeks calculation frequently needs a workaround or a separate compliance tool to be reliable.
IR35 contractor classification: Bullhorn does not have a native IR35 field. This is a custom field that has to be created. Reporting on IR35 status across the contractor base is possible once the field exists, but agencies regularly forget to create it until an HMRC review is already underway. If you are placing contractors and do not currently have an IR35 field on your placement or candidate record, add it now.
Gender pay gap reporting: UK employers with 250 or more employees are required to report gender pay gap data annually. Recruitment agencies above that threshold should be drawing this data from payroll, not from Bullhorn. If candidate gender data is held in Bullhorn and someone suggests using it for GPG calculations, that creates GDPR considerations worth thinking through carefully before proceeding. The payroll system is the correct source of truth here.
Right-to-work document expiry: Bullhorn's compliance checklist module can hold document expiry dates, and a report pulling contractors whose right-to-work documents expire within the next 60 days is achievable natively. The caveat is the same as it always is - only if the data is being entered consistently. A compliance report against an incomplete dataset is worse than no compliance report, because it creates false confidence.
Which data quality problems will break your Bullhorn reports?
Four data problems break Bullhorn reports more often than anything else: duplicate candidate and company records that split or double-count activity, inconsistent sector taxonomy that makes any segmented report meaningless, placements missing bill rate, pay rate or fee data, and date errors on contract placements. None of them produce an error message. The reports run and return numbers that look plausible, which is why they go unnoticed for months.
These are the failure modes that undermine Bullhorn reporting and analytics for UK agencies most consistently.
Duplicate records inflating activity metrics: a consultant submits the same candidate under two records, or a company exists as both "Acme Ltd" and "Acme Limited". Activity gets split or double-counted depending on how the report is structured. Bullhorn has a merge function, but it is manual, time-consuming, and has to be repeated regularly if duplicates are not caught at point of entry. Before launching any activity dashboard, run a report on contacts and companies with matching email domains or very similar names. Deal with the duplicates first.
Inconsistent sector taxonomy: if consultants use "Technology", "Tech", "IT", and "Information Technology" interchangeably in the sector field, any report segmented by sector is meaningless. This is extremely common in agencies that grew through acquisition or that allowed free-text entry before moving to a controlled picklist. Fixing it is a data cleanse exercise - there is no Bullhorn configuration that retroactively corrects inconsistent historical values. The remediation is export, remap, reimport, and then lock the field to a controlled list going forward.
Missing placement financial data: placements recorded without bill rate, pay rate, or fee amount are invisible to margin reports. The placement appears in volume counts but drops out of every financial calculation. This is particularly common for placements entered retrospectively to close out a period, or for trial arrangements where the fee structure was uncertain at the time of entry.
Date field errors on contract placements: a contractor end date entered as 2024 instead of 2025 will cause the placement to appear to have ended. It drops out of active contractor reports, potentially triggers AWR miscalculations, and looks completely valid to the system - Bullhorn will accept the date without flagging it. Date errors are hard to catch precisely because they are not obvious. A placement that silently disappears from the active list is easy to miss until someone notices the contractor is still actually working.
The practical first step is to export all placements from the last 12 months and check for null values in the bill rate, pay rate, and GP fields in Excel. Then cross-reference the placement count against the invoice count in your finance system for the same period. The gap between those two numbers is the size of your data problem.
When should you move beyond Bullhorn reporting to Cube19 or a BI tool?
Bullhorn's native reporting is adequate for most agencies up to around 30 to 50 consultants, assuming the data is clean. Beyond that scale, the volume of report requests from different stakeholders, the need for cross-entity reporting, and the visual limitations of Canvas push agencies towards a third-party tool.
There are three realistic options at that point:
Cube19: the most common UK-specific Bullhorn analytics add-on. It adds real-time dashboards, consultant performance league tables, and KPI targets with traffic-light status indicators. The UI is considerably better than Canvas. What it does not do is fix underlying data problems - Cube19 will surface bad data more attractively, which is not an improvement. My recommendation is to address the data quality issues covered above before considering Cube19. If you invest in Cube19 before the data is clean, you will get a polished dashboard showing numbers you cannot trust. That is a worse position than a basic Canvas report showing numbers you know are incomplete.
Power BI or Looker via the Bullhorn REST API: relevant for agencies with multi-entity structures, or where Bullhorn data needs to be blended with finance system or payroll data. The Bullhorn REST API is well documented and can feed a data warehouse or a direct connector. The honest cost is 10 to 20 days of development time minimum for a meaningful initial build, plus ongoing maintenance. This is a development project, not a configuration project. Budget accordingly. Do not start this path without a clear owner for the technical pipeline, because it will break and someone needs to fix it.
Staying with Canvas and fixing the fundamentals: for most agencies under 50 consultants, this is the right answer. A well-configured Canvas setup with clean data will answer the questions most agencies actually need answered. The temptation to buy a better reporting tool before the data is in order is a way of spending money on the wrong problem.
The decision comes down to three questions: how many stakeholders need reporting access across different entities or data sources, does the reporting need to blend Bullhorn data with non-Bullhorn data, and is there budget and technical resource to build and maintain an integration. If the answer to all three is broadly "no", fix Canvas first.
How do you get consultants to actually use the reports?
Consultants use a report when it is pushed to them, short, and attached to something they already do. Schedule delivery by email rather than expecting anyone to go and find a dashboard, hold consultant-facing reports to about four metrics, and make the report the agenda for a meeting that already exists. After that it comes down to managers: if the manager never references the report, consultants correctly conclude it does not matter.
The most common outcome of a Bullhorn reporting project is a well-built dashboard that nobody checks after the first two weeks. Adoption is the problem, not the build. I have seen this happen on technically correct implementations where the dashboards were exactly what was asked for - the issue was never the reports themselves.
A few things that actually help:
Push the reports rather than waiting for consultants to pull them. Bullhorn supports scheduled report delivery by email. A report that arrives in someone's inbox at 8am on Monday gets looked at. A dashboard that requires three clicks to locate does not. Set up scheduled delivery for consultant-facing reports and remove the friction entirely.
Limit what consultants see. Four metrics: calls made this week, CVs sent this week, interviews arranged this week, placements this month. If the report tries to show everything, it communicates nothing. A 15-metric consultant dashboard is a 15-metric consultant dashboard that nobody uses.
Tie the report to a habit that already exists. If there is a Monday morning team meeting, the report is the agenda. If managers review pipeline on Friday afternoon, the report is on screen. Reporting adoption fails when it asks consultants to form a new behaviour. It works when it supports something they are already doing.
Managers bear most of the responsibility for adoption. If the manager is not referencing the report in one-to-ones, consultants will correctly conclude that it does not matter. The report becomes background noise. The fix for that is a management behaviour change, not a dashboard redesign.
One more thing worth noting: hiding certain metrics from consultants is sometimes the right decision. Margin data at deal level, for example, is not information every consultant needs to see. Surfacing it can create friction around pricing conversations that you would rather not have. Canvas does allow report-level access controls - use them.
Getting value from Bullhorn reporting and analytics in a UK recruitment context is not primarily a technical challenge. It is a question of whether the right data exists, whether the right people are looking at the right metrics, and whether someone has thought through what decision each report is supposed to drive. That is the kind of question worth working through before you spend time building dashboards. If you want to work through it for your business, a Bullhorn CRM audit is where to start.
