I came to gradient‑boosted trees as a tax lawyer working on audits, not as a data‑science purist. At Deloitte’s tax audit department, I help very large companies manage complicated tax audits—explaining anomalies in their accounting and reconciling them with tax declarations. Finding anonalies is easy, explaining them a bit less, you need to find a pattern and a story to back them. So model accuracy wasn’t the roadblock—explainability was. Controllers and inspectors don’t accept “because the model said so.” They want an audit trail: Which variables pushed this entry into the suspect bucket, and why now?
To make that conversation possible, I built and shipped feature‑importance into the open‑source XGBoost project and made it easy to visualize. Overnight, a forest became a ranked, defensible list of signals—something you can paste into a memo, discuss in committee, and act on.
Want the longer version I used with finance and audit teams? Here’s the deck on SlideShare: Feature Importance Analysis with XGBoost in Tax Audit.
The contribution that changed the conversation
What it gives you. After training, you press one button and get a sorted table and bar chart of what drove the model. No spelunking through dumps, no bespoke scripts—just a ranking you can take to an audit. Because it’s open source, the logic is visible, reproducible, and reviewable by anyone on the engagement.
How to read it like an auditor.
- Start with Gain. Treat it as “how much this feature helped reduce error.” If VAT code = special rate ranks high on Gain, that’s a lead: Why do these codes concentrate in flagged lines this quarter?
- Use Frequency and Cover as supporting evidence. Frequency shows “workhorse” variables used across the forest; Cover shows breadth—features touching large chunks of the data.
- Linear booster baseline? Rank by the absolute coefficient (with standardized inputs) so the order means something to your legal or economic narrative.
Why it mattered in tax audit.
This turned a black‑box model into a short, actionable list:
- Prioritized sampling — If last‑day‑of‑quarter booking and round‑number amounts bubble to the top, start your samples there.
- Targeted document requests — Reverse‑charge VAT × supplier country → request invoices and customs docs for that slice.
- Sharper control tests — If manual journal codes dominate, test approvals around off‑system postings.
- Clear memos — “Here are the top five drivers behind our anomaly flags on the FEC,” without exposing the entire model internals.
Why I insisted on doing it open source
- Auditability ≠ marketing slide. Open code means your method can be checked—by internal audit, external auditors, or a regulator.
- Reproducibility. Same data, same version, same settings → same ranking. That consistency is what makes evidence defensible.
- Community scrutiny. Design choices (e.g., how Gain is computed) live in public PRs and issue threads, not private PDFs.
- Vendor independence. You can move models and explanations across systems without rewriting the story every time.
The companions I used, kept short and pragmatic
- One‑forest overview. A multi‑tree projection compresses the whole ensemble into a single, readable picture—useful when you must explain how the forest reasons without paging through 200 trees.
- Depth diagnostics. A deepness view shows where splits actually happen—are your trees truly shallow enough for governance constraints, or do interactions only appear late?
- When you must show a path. Tree diagrams are crisp enough for appendices and slide decks.
- Leaf indices as features. Predict leaf IDs and use them as engineered features for downstream triage or rule mining when the audience prefers binary indicators.
All of these were built and polished in the open—raised as issues, reviewed as PRs, and improved by maintainers and users who cared about turning accuracy into accountable decisions.
A checklist I gave finance teams
- Lead with Gain; use Frequency/Cover for corroboration.
- Think like a lawyer: a strong signal without a plausible tax mechanism is a prompt to investigate data quality or interactions—not a conclusion.
- Cross‑check structure: top‑ranked features should appear early or often; if not, look for interactions.
- Close the loop: convert the top drivers into sample plans, document requests, and control improvements.