FINANCE // TECHNOLOGY // DESIGN
I closed the books. Then I wrote the software that closes them.
Interim Director, Journal Entry Accounting for a national health system — 68 hospital campuses, 300+ sites of care, 49 accountants. The Python automation every one of those journal entries now arrives through is also mine.
Most finance leaders at that scale talk about the automation they sponsored. I wrote mine — no vendor, no statement of work, no IT ticket going stale in a queue — because I have been shipping production code since 1998 and saw no reason to ask permission to do my own job. Thirty years ago that made me unusual. What it makes me now is useful, and the rest of this file is the argument for why.
01 PROFILE
It is the one where the accounting is wrong because the system is wrong, and fixing it needs someone who understands the ledger, the operation that produced the transaction, and the code underneath — at the same time, in the same head.
Normally that takes three people and a translation layer. A controller who knows what the number should be. A business analyst to write it down. An engineer to build something approximately like what was written down. Six months later everyone agrees the requirements were misunderstood.
I am all three, which is the only reason I know how badly those roles usually understand each other. I have closed the books and written the software that closes them. I have been the CFO and the developer on the same problem in the same week.
Give me a broken process and I will tell you whether it is an accounting problem, an operations problem, or a software problem — and then fix it, whichever one it turns out to be.
THE USUAL ANSWER
WHAT ACTUALLY HAPPENED
Sponsored an automation initiative.
Identified the problem, designed the workflow, wrote the automation, validated the accounting logic, and deployed it.
Gathered requirements for the developers.
Already had the requirements. I was the one doing the work.
Built a financial system from a technical specification.
Built it knowing what the trial balance was supposed to look like when it was done.
Escalated to IT and waited.
Shipped it Tuesday.
What I do not do is write a deck about what should be built and leave. I have never delivered a recommendation I was not willing to implement myself, and I am not starting now.
02 OPERATING SYSTEM
The jobs look unrelated on paper — hospital finance, state government software, industrial operations, national signage, a trail app. They are the same job. This is the loop, and it has not changed since 1998.
Usually one everybody has stopped seeing, because working around it has become the job.
Not broken enough to replace. Just bad enough to cost somebody four hours every Tuesday, forever.
Because I have done the work by hand. Requirements defined from ownership, not from an interview.
What it does to the close, the control environment, the audit, and the P&L. In that order.
Well enough to build the better version rather than describe it to somebody who will build something adjacent.
Working software, on real data, usually before the meeting to discuss it has been scheduled.
This is the step everyone skips. It is also the only one that determines whether any of the others mattered.
Accounting is not really about arithmetic. It is about verification — refusing to accept a number because it looks right, tracing it to a source, and knowing precisely how confident you are entitled to be. That is the same discipline that separates software which demos well from software that works, and it is the thread running through every unrelated-looking job in this file.
It shows up in odd places. Building the trail app on this domain, I checked a state agency's published coordinates against its own published mileposts and found entries that were physically impossible — points whose straight-line distance exceeded the trail distance between them. Two more had transcription errors that would have put a rider in the wrong state. Nobody asked me to audit a government PDF. Reconciling is simply what I do to data before I trust it.
An engineer would have shipped those coordinates. An accountant would have caught them and filed a ticket. I caught them and fixed them before lunch.
The same instinct is what is useful when something is actually on fire. During the national Kronos outage I rebuilt payroll data by hand and kept a hospital operating on stopgap systems for weeks. Years earlier I oversaw 1,600+ subcontractors and executed 6,000+ site installations in 90 days — a company record — and led the national rebranding conversions of BankOne to Chase, MBNA to Bank of America, and Cingular to AT&T.
The pattern never changes. The thing has to work, the deadline is not moving, and somebody in the room has to actually know how to do every part of it. I have spent thirty years being that person, usually because nobody else volunteered.
03 BUILT SYSTEMS
Eight files. Sole author on every one of them. Each opens into a full case study — the problem, the old process, the architecture, the controls, and what it actually changed.
Lifepoint Health · 2026
The intake point for journal entries across a national health system.
Independent build · 2026
An agent that drafts the entry. A human still signs it.
Independent build · 2025 — present
Excel is the cockpit. PowerShell is the engine. The model never touches an order.
Clinch Valley Medical Center · 2014 — 2026
96+ hours a month, and a full business day off the close.
Northrop Grumman · 2008 — 2011
Written alone. In production for more than ten years.
Burch Industrial Group / KNL Holdings / KNL, Inc. · 2024 — 2025
$228K out of the annual cost base. It started with measurement, not cuts.
Independent build · 2025 — present
A GPS dashboard for rail-trails. Zero mapping libraries.
Across roles · 1998 — present
Twenty-five years of the small things that quietly ran a finance department.
OPEN CASE FILEFiles awaiting release
Work I have done that is not written up here yet, either because the case study is still being drafted or because it needs sanitizing before it is public. Listed rather than omitted, because a dossier with gaps you can see is more credible than one that implies there are none.
04 THE CLOSE
Every month, in most finance departments on earth, a group of capable people rebuild the same work by hand under a deadline, and call the result a process. It is not a process. It is a habit with a due date.
The work divides cleanly, and almost nobody divides it. Repetition belongs to software. Judgement belongs to people. What actually happens is the reverse: the accountants spend the first eight days retyping, and the exceptions — the part that genuinely needs a human — get whatever attention is left at four o'clock on close day.
So the design goal is not a faster close. It is a smaller one. Take the repetition out entirely, and hand the humans a queue of things that are actually interesting: the anomaly, the missing activity, the distribution that does not belong, the number that balances beautifully to the wrong answer.
A conceptual reference architecture, not a diagram of any employer's systems.
Operational and source data arrives on a schedule instead of being fetched by a person.
Transactions are typed and routed. Accruals, prepaids and allocations identify themselves.
Amortization, allocation and auto-reversing logic run deterministically. Same inputs, same answer, every time.
Balance checks, duplicate detection, missing-activity detection, distribution validation. Fail loudly, fail early.
Entry, support schedule, assumptions and audit trail are produced together — because support written later is not support.
Anything the rules cannot clear goes to a human with the context already attached.
A person approves. Always. The signature is not a formality and it does not get automated.
Into the ERP, with the trail intact and reproducible from source.
THE CLOSE AS A HABIT
47 steps12 files6 handoffs3 hours
The data arrives. Nobody fetches it.
A person reads exceptions, not formats.
The signature is the control. It stays human.
With the support and the trail already attached.
Forty-three of those steps were never decisions. They were somebody moving a number from one place to another and hoping they did not fat-finger it.
Illustrative. A generic manual close, not a measurement of any employer's process — the 47 steps are what this work looks like almost everywhere before somebody redesigns it. The point is the shape of the change, not the arithmetic.
Most companies are somewhere between the second and third conversation about AI and have nothing in production. Not because the technology is not ready. Because nobody in the room understands both the model and the process well enough to say where it belongs — and, more importantly, where it does not.
The vendors will sell you a platform. The consultants will map your journey. Neither has closed your books, run your intake queue, or answered the phone when the thing broke. So you get a pilot that demos beautifully, never survives contact with a real exception, and quietly dies as shelfware nobody will admit to buying.
A model that is right ninety-four percent of the time is remarkable, and completely unacceptable for a control that has to be right every time. AI belongs in the middle, and most businesses are pointing it at the ends.
The failure mode is not the one people brace for. AI will hand you a broken map projection, a coordinate in the wrong hemisphere, or a reconciliation that balances beautifully to the wrong number — and it will do all of it with total confidence. If you cannot tell, you ship it and you find out in an audit. Thirty years of doing the work by hand is the difference between leverage and a very fast way to be wrong.
An AI you cannot audit is a liability wearing a productivity costume.
05 CAREER RECORD
Nine chapters, four disciplines, one method. Select a chapter to open the record.
National health system · corporate accounting and shared services
Own journal entry accounting for a national health system while a nationwide shared-services consolidation is actively pulling that work out of hundreds of facilities and into one centralized group.
Scope
Key problems
What I changed
What I built
Business impact
Leadership
Tools & systems
Centralization does not create a benefit on its own. It relocates the work. The benefit comes from standardizing the shape of what arrives — and that is an accounting policy decision before it is ever a software one.
Newly formed centralized accounting group
Close the books for a multi-facility portfolio inside a centralized accounting group that was itself three weeks old.
Scope
Key problems
What I changed
What I built
Business impact
Leadership
Tools & systems
The fastest route to influence in a new organization is to build the thing everybody needs and nobody has time to design.
Right-of-way, vegetation management and construction
Run three companies as senior-most operator and de facto CFO, with full licensing authority and P&L ownership — while holding a full-time hospital finance role.
Scope
Key problems
What I changed
What I built
Business impact
Leadership
Tools & systems
You cannot cut a cost you cannot see. Instrument first; the expensive decisions stop being arguments and start being obvious.
Lifepoint Health · 100+ bed acute care hospital
Serve as the analytics, automation and systems resource to the CFO, Controller and department leadership — twelve years in one production hospital finance environment.
Scope
Key problems
What I changed
What I built
Business impact
Leadership
Tools & systems
Twelve years in one department is long enough to stop seeing the process and start seeing the waste. That is not a tenure problem. It is where the automation ideas come from.
Run a retail operation on numbers rather than instinct.
Scope
What I changed
What I built
Business impact
Leadership
Tools & systems
The instinct to build the tool rather than ask for one does not care what industry you are in.
Teach software engineering to college students and working professionals while working as a developer full-time.
Scope
What I built
Business impact
Leadership
Tools & systems
Teaching a thing is the fastest way to find out whether you actually understand it. Recommended, and slightly humbling.
Commonwealth of Virginia account
Build and support the applications a hundred state agencies depended on — and coordinate the response when something statewide went down.
Scope
Key problems
What I changed
What I built
Business impact
Leadership
Tools & systems
I gathered the requirements because I was the one answering the phone at three in the morning. That is still the most efficient requirements process I have ever been part of.
Execute national rollouts at a scale where coordination is the entire product.
Scope
Business impact
Leadership
Tools & systems
At six thousand sites, nothing survives that depends on somebody remembering. The system either works without heroics or it does not work.
Design national signage and architectural branding systems — and find out that the manufacturing cost is a design decision.
Scope
What I built
Business impact
Tools & systems
Where the code started. Design taught me that the expensive mistakes are made early, in the drawing, long before anyone builds anything.
06 RANGE
Four disciplines. One method. The connective tissue is systems thinking — whether the system is made of numbers, people, workflows, software or steel.
FINANCE & ACCOUNTING
ENGINEERING
OPERATIONS & LEADERSHIP
DESIGN & CRAFT
languages/
Python · SQL · JavaScript · C# / .NET · VBA · Visual Basic · PowerShell · Java · HTML/CSS
llm-and-agents/
Anthropic Claude API · prompt and system-instruction design · tool calling · multi-step orchestration · context management · retrieval-augmented generation · agent output evaluation · Model Context Protocol (studying the specification and integration patterns)
ai-security/
Prompt injection and jailbreaking risk · sensitive-data handling in a healthcare environment · insecure tool execution · least-privilege tool and system access · secrets management · output validation before write-back · OWASP software security principles
platforms/
ASP.NET / .NET Framework · progressive web apps · Oracle Cloud · Azure · Microsoft 365 · SharePoint · Power Platform · ServiceNow · Okta · REST/JSON APIs · Stripe · geospatial tile services
finance-systems/
Oracle Cloud ERP and Oracle Fusion · enterprise GL and ERP · hospital financial and payroll systems · Kronos · enterprise reporting environments · RPA design and deployment · dashboarding, variance and productivity analytics
practice/
SDLC · requirements defined from operational ownership rather than interview · architecture and data modeling · validation and error handling · code review · technical documentation · production deployment and long-horizon support
EDUCATION & CERTIFICATION
Steel lattice · built to be climbed · still standingThe same shape as a railway trestle, which is what the trail app is named after. Thirty years of looking at how things are put together and you stop being able to switch it off.
07 PROOF
Virginia runs on more than a hundred state agencies and offices. I wrote applications that supported critical functions across them — agency account management and statewide outage tracking — and I wrote every line of them.
Not a team. Not a vendor. Concept, data model, code, deployment, documentation and support: all mine. I gathered the requirements because I was the one answering the phone at three in the morning when something broke, so I already knew what the software had to do. Then I built it, put it into production, wrote the SME documentation that standardized the procedure statewide, and supported it.
Those systems ran for more than ten years.
Software written by one person, holding up under a hundred agencies' daily use for a decade, is the only credential I have that I would put ahead of any title.
When I run into something unnecessarily difficult, repetitive, ugly or confusing, I do not file it under how things are. I start building the better version, usually before deciding whether I am allowed to.
That has meant a spreadsheet and it has meant an enterprise application. It has also meant an accounting process, a dashboard, a workflow, a team structure, a website, a utility nobody sells because the requirement is too specific, a deck, a basement, tables, chairs — and, on at least one occasion, a steam whistle synthesized from oscillators because an audio file felt like cheating.
The through-line is not the technology. It is the refusal to accept that the current version is the final version. I draw, I paint, I sculpt, I tattoo and I work wood, and none of that is a hobby I keep away from the day job — it is the same instinct, pointed at a different material.
NOT ALL OF IT IS SOFTWARE
The best projects almost always begin with somebody saying: this should be easier.
09 ASK THE DOSSIER
A retrieval interface over this dossier's own content. It answers from what is written here and nothing else — no model, no generation, no invention. If the file does not contain the answer, it says so and offers you a better route.
08 CONTACT
Two situations, and I am worth the money in both.
THE FIRST IS A MESS
A close that takes too long, a control nobody can explain, a process held together by one spreadsheet and one person's memory. I like these. The work is diagnosis before construction, and most people skip straight to construction.
THE SECOND DOES NOT EXIST YET
Software no vendor sells because the requirement is too specific to one business. That is the work I have done most often and enjoyed most, and the part people underrate is the last step: staying until it actually works.
IF YOU ARE HIRING FOR FINANCE OR OPERATIONS
You get someone who runs the function and can also fix the system producing the numbers. Journal entry governance across 300+ sites of care, a nationwide centralization in flight, 49 accountants — and the automation underneath, written rather than bought.
IF YOU ARE HIRING ENGINEERS OR BUILDING AI
You get an engineer who does not need requirements gathered, because he is the business owner of the process being automated. Production code since 1998, enterprise systems that lived ten years, and agents built on the Claude API against work he is personally accountable for.
RECONCILIATION
FILE AHB-1998 · AS AT BUILD
✓ TIES
Every count above is computed from this site’s own content files at build time, so it cannot drift from the page. Four case studies are listed as unwritten rather than quietly omitted, and every facility-level number says so where it appears. A dossier with the gaps showing is worth more than one that implies there are none — and reconciling before you trust something is, more or less, the entire argument of this file.
The fastest way to know whether I am useful to you is to describe the problem and see whether I ask better questions about it than you expected. That conversation is free.