Archive

Tag Archives: ai

ERP Fraud Files, Part 11: The General Manager Who Put His Wife on a Subcontractor’s Payroll

By
October 2, 2026
Uncategorized
Leave a comment

Mark Angarola ran as the global account general manager for an IT services firm supporting a financial institution's operations. For nine years, from roughly May 2010 through February 2019, he arranged for a subcontractor to employ people who did little or no real work for the account he managed, among them his wife, his college roommate, and several friends. He was sentenced in December 2025 to 38 months in prison. The total loss came to more than $8.3 million, with restitution ordered at $9,023,444.96 and forfeiture at $2,679,445.26.

What happened

Angarola had authority to approve invoices from a subcontractor working under his account, and he used that authority to get his own people onto the subcontractor's books. According to prosecutors, he arranged for the subcontractor to hire his wife, a college roommate, and other friends and family, then signed off on timesheets and invoices representing work they hadn't performed. Running alongside the ghost-employee scheme was a second one: expense claims. He submitted and got reimbursed for restaurant meals, hotels, transportation, cruises, and visits to gentlemen's clubs, all disguised as legitimate business costs tied to the account.

He also failed to report the income from either scheme on his taxes for four years, and filed no returns at all for two of those years, a detail that cost the IRS an additional $668,000 and tends to be the thread that eventually gets pulled when investigators start reconstructing what someone actually earned against what they reported.

Why the gap existed

Most of this series has involved someone defeating a control that existed on paper but failed in practice. This case barely had a control to defeat. Angarola held unilateral approval authority over the subcontractor relationship he was simultaneously using to employ his own friends and family. Nobody else at the contractor needed to sign off on who that subcontractor hired, what they were paid, or whether the work billed against the account actually happened.

Ghost employees are a particular kind of fraud because the fictitious worker usually exists somewhere on paper: a name, a timesheet, an invoice line. What's missing is the labor behind it, and that absence is invisible to a system that only checks whether an invoice matches a purchase order and a contract rate. An ERP comparing an invoice against an approved subcontract agreement will clear a bill for forty hours of work at the agreed rate every time, whether or not anyone actually sat at a desk and did the work.

The expense fraud exploited a related blind spot. Expense reports get approved against policy limits and receipt requirements, not against whether the trip or the meal served any legitimate business purpose tied to results anyone can point to. A cruise or a night at a club can be coded as client entertainment and sail through an approval workflow that only checks for a receipt and a dollar threshold, especially when the approver and the person submitting the expense are effectively the same authority.

Controls that would have caught it

Independent verification of subcontractor labor against deliverables. Invoiced hours need to trace to work product, a deployed fix, a completed task, a meeting record, something beyond a timesheet the subcontractor itself generated. A review process that spot-checks a sample of billed hours against actual deliverables would have surfaced names that never produced anything to show for nine years of billing.

A hard prohibition on approving invoices tied to your own personal relationships. Anyone with invoice or timesheet approval authority over a vendor or subcontractor needs to disclose personal relationships with anyone on that vendor's payroll, and approval needs to shift to someone outside that relationship entirely. This is a conflict-of-interest control more than a financial one, but it's the control that actually would have stopped this specific scheme at the source.

Expense review tied to business outcome, not just policy compliance. An expense approval process built only to check receipts and dollar limits will approve almost anything coded correctly. Periodic review that asks what business result a given expense produced, tied back to a specific deliverable or client interaction, catches spending that's procedurally compliant and substantively fictitious.

An AI prompt example for ERP fraud detection

This case needs queries that look past procedural compliance toward whether billed labor and expenses correspond to anything real. Against a vendor management and accounts payable module, someone could run something like:

"List all subcontractor employees billed against this account for the last five years, cross-referenced against any family or personal relationship disclosures on file for the approving employee."

A second query targets the expense side:

"Flag all expense reimbursements coded as client entertainment or business travel where the approving manager and the submitting employee are the same person, or where no corresponding client meeting or deliverable is logged in the account record."

Neither query requires suspecting anyone by name. It requires treating an approval authority held by one person over their own account as something that needs a second set of eyes, which is the specific thing nobody built into this relationship for nine years.

The pattern for this series

Nearly every case in this series comes down to someone holding both ends of a transaction that's supposed to have two separate hands on it. Sometimes that's a payment and its approval. Sometimes it's a ledger and the records used to check it. Here it was an entire subcontractor relationship, employment and billing and approval all resting with one person, for the better part of a decade.

Source disclaimer

The case details in this article are drawn from a press release published by the U.S. Attorney's Office for the Southern District of New York, a public government source, along with contemporaneous news and IRS Criminal Investigation reporting on the same case. All facts, figures, and quotations describing the case are sourced from those releases and reports. The analysis of the control gap, the proposed detection controls, and the AI prompt examples are original commentary and are not part of the source material.

References

United States Attorney's Office, Southern District of New York. "Tech Company Executive Sentenced To Prison For Multimillion-Dollar Embezzlement Scheme And Tax Evasion." Press release, December 2025. https://www.justice.gov/usao-sdny/pr/tech-company-executive-sentenced-prison-multimillion-dollar-embezzlement-scheme-and

Internal Revenue Service Criminal Investigation. "Tech company executive sentenced to prison for multimillion-dollar embezzlement scheme and tax evasion." https://www.irs.gov/compliance/criminal-investigation/tech-company-executive-sentenced-to-prison-for-multimillion-dollar-embezzlement-scheme-and-tax-evasion

Hoodline. "Former Tech Executive Sentenced to 38 Months for Multimillion-Dollar Embezzlement and Tax Evasion." https://hoodline.com/2025/12/former-tech-executive-sentenced-to-38-months-for-multimillion-dollar-embezzlement-and-tax-evasion/

ERP Fraud Files, Part 10: The Bookkeeper Who Renamed Herself After the School

By
October 1, 2026
Uncategorized
Leave a comment

Alysa Dietz Gisser was the bookkeeper and accountant for a small Austin nonprofit school serving children with learning disabilities and special needs. Starting around 2018, she had parents send tuition payments to a PayPal account she controlled, one she had renamed to match the school's own name. She was sentenced in 2026 to 33 months in federal prison and ordered to pay $1,318,684.34 in restitution, on top of a money judgment of just over a million dollars.

What happened

The mechanism here doesn't involve the school's ERP or accounting system at all, at least not at the point of theft. Gisser controlled a PayPal account tied to her own consulting business and renamed it to read like the school's official payment account. Parents paying tuition, enrollment fees, or other charges had no reason to look twice at a payment destination that displayed the school's name. The money went to Gisser instead of the school, every time, for roughly three years.

Making the accounting records lie was the second half of the scheme and the harder one to pull off cleanly. Gisser modified the school's internal accounting files to show tuition payments as received in full, which meant the school's own books looked healthy while the actual bank balance wasn't. Prosecutors also found she'd underreported her income by $863,963.32 over the same period, the kind of detail that only comes out once investigators start pulling bank records rather than trusting what's on a ledger.

Why the gap existed

Every case earlier in this series involved a weakness somewhere inside the ERP itself: a vendor record, a payroll deduction, a reconciliation process. This one starts outside the system entirely, at the moment a parent decides where to send a tuition check, before any of it ever touches an accounts receivable module. That's a genuinely different kind of control gap, because the fraud doesn't need to defeat anything built into the software. It only needs the payment to go to the wrong place before the ERP ever has a chance to record it accurately.

The accounting-side cover-up is where this case rejoins the pattern the rest of the series has been tracking. A small nonprofit school with one bookkeeper handling both the collection of tuition and the recording of whether it arrived has no separation between those two functions. Gisser could misdirect a payment and then personally update the system of record to say the misdirected payment had actually come in. Nobody cross-checked the accounting entries against anything outside her control, so the entries simply became the truth as far as the school's own books were concerned.

A school serving a small number of families, where tuition often gets paid in installments through whatever channel is most convenient for a parent, is a specific kind of soft target. There's no large accounts receivable department running standardized collection. There's a bookkeeper who parents call directly when they have a billing question, and that same person decides what the books say happened.

Controls that would have caught it

Payment channel verification independent of the bookkeeper. Any payment destination, whether a bank account, a PayPal account, or any other external channel, needs to be registered and verified by someone other than the person who manages day-to-day accounting. A new or renamed payment account should trigger a notification outside the bookkeeper's own control, not just appear quietly in the payment flow.

Reconciliation against an external source, not the bookkeeper's own entries. The school's accounting files said tuition had been received. The actual PayPal and bank records would have said otherwise, if anyone had been comparing the two. A reconciliation process that pulls transaction data directly from the payment processor, rather than accepting whatever the bookkeeper enters, closes this specific gap.

A published, unchanging payment destination communicated directly to families. Parents had no independent way to confirm the PayPal account they were paying actually belonged to the school. A payment portal or published account reference maintained outside the bookkeeper's reach, ideally confirmed through a second channel like a board member or a separate administrator, removes the opportunity to substitute a lookalike destination in the first place.

An AI prompt example for ERP fraud detection

This case needs a query aimed at the gap between recorded revenue and verified incoming payments, which most small organizations never build because the volume seems too low to justify it. Against an accounts receivable module paired with payment processor records, someone could run something like:

"Compare all tuition or payment records marked as received in the accounting system against the corresponding settlement records from the payment processor for the same period, and flag any entries with no matching external transaction."

A second query targets the payee-impersonation angle directly:

"List all payment account names or identifiers associated with the organization's name that were created or modified in the last five years, along with the account holder of record for each."

Neither query assumes anyone inside the organization knew something was wrong. Both assume the organization's own books are not sufficient evidence of what actually happened, which is the specific lesson this case keeps offering.

The pattern for this series

Most of the cases in this series involve someone finding a weak point built into the ERP itself. This one is a reminder that a control gap doesn't need to live inside the system at all. It can sit one step upstream, at the moment money chooses a destination, with the ERP only ever seeing the version of events the fraudster chose to type in afterward.

Source disclaimer

The case details in this article are drawn from a press release published by the U.S. Attorney's Office for the Western District of Texas, a public government source, along with contemporaneous news reporting on the same case. All facts, figures, and quotations describing the case are sourced from those releases and reports. The analysis of the control gap, the proposed detection controls, and the AI prompt examples are original commentary and are not part of the source material.

References

United States Attorney's Office, Western District of Texas. "Former Austin School Bookkeeper Sentenced for Embezzling Over $1M." Press release, 2026. https://www.justice.gov/usao-wdtx/pr/former-austin-school-bookkeeper-sentenced-embezzling-over-1m

Fox 7 Austin. "Former Austin private school bookkeeper embezzled $1M for home pool, mortgage." https://www.fox7austin.com/news/former-austin-private-school-bookkeeper-embezzled-1m-home-pool-mortgage

KXAN. "DOJ: Leander woman embezzles over $1M from Austin school." https://www.kxan.com/news/crime/doj-leander-woman-embezzles-over-1m-from-austin-school/

The Meter Was Always Running

By
September 30, 2026
Uncategorized
Leave a comment

In the late 1970s, a text gaṃe called Colossal Cave Adventure started closing its cave during business hours. Don Woods had built in ṃachinery that locked players out during prime-time computing, and Donald Knuth later wrote that he believed John McCarthy insisted on it after watching the productivity of his Stanford AI Lab drop off sharply. Knuth also passed along the ruṃor that McCarthy kept a special version that let him play whenever he wanted.

That cave is a fair preview of the AI budget ṃeetings happening now. A new technology lands on shared, expensive infrastructure, and people use it for things nobody planned for. Then the person in charge rations it and keeps a private copy for hiṃself.

If you’re rolling out Copilot seats or handing API keys to a developṃent team, the first real invoice may not look much like the business case. That tends to get treated as a new probleṃ. It isn’t. Metered technology has been surprising the people who pay for it for about sixty years, and the fixes have been dull enough that each generation seeṃs to forget them.

Paying by the second

Tiṃesharing came first. Through the 1960s and 1970s, service bureaus rented out terṃinals and then billed for connect time by the hour and CPU time by the second. It was a real industry: by 1968 the National Institutes of Health alone was served by 32 of these bureaus, and a 1973 guide listed 125 tiṃesharing services.

Soṃe of those bills landed on people who never expected to see them. One forṃer UMass graduate student recalled finishing his dissertation and getting a bill for several thousand dollars of mainframe time. The university waived it for graduate students.

The photocopier is the closer parallel, though. Before the Xerox 914 arrived in 1959, a typical office copier turned out 15 to 20 copies a day. The 914 averaged about 2,000. Xerox leased the ṃachines instead of selling them and charged by the copy, betting that workers would get hooked on the convenience.

The bet paid. By 1962 the coṃmercial copying business was worth $400 million, against $40 million ten years earlier, and nobody had to abuse anything to produce that curve. People copied because copying had become easy. Municipal copier leases still list departṃent accounting codes as a feature.

Locks on the dial

In 1981 the Christian Science Monitor put office phone abuse at about $4 billion a year for Aṃerican businesses, roughly 40 percent on top of what they paid for legitimate calls. I’d treat that as an estiṃate. The specific cases are easier to believe: the federal governṃent counted 798,000 unauthorized long-distance calls in 1978, and New York’s General Services Agency was losing about $3,000 a month to 50,000 unauthorized calls placed by 15,000 employees.

Johnson & Johnson bought plastic phone locks at $12.95 apiece. One ṃanager’s bill, which had been carrying 75 calls a month, most of them unauthorized, dropped to zero toll calls. Computer blocking systems cost between $65,000 and $200,000. Kellwood, a clothing ṃanufacturer, installed one and watched monthly toll calls fall from 30,000 to 23,000, with the average call shrinking from seven minutes to five, for savings of about $125,000 a year.

Massachusetts General Hospital rented a tracking systeṃ for $500 a month and cut its $40,000 monthly toll bill by 38 percent. Systeṃs like that worked largely by printing out each person’s calls and handing them the list.

Local calls ran a ṃeter too. New York Telephone started tiṃing local calls in its major cities during the 1970s, and most untimed business lines disappeared that decade, so a clerk’s call to a supplier across town had a price attached. In Britain the meter lasted into the dial-up era. Households rationed their internet tiṃe to control the phone bill until BT offered unmetered weekend access in June 1999, and by April 2000 Telewest, NTL, Freeserve and Virgin.net were all selling unmetered service.

Governṃent kept losing this fight into the 1990s. A 1996 GAO audit found USDA had accepted 652 collect calls from inmates at 18 correctional facilities over a few months, about half of all the collect calls it took. The departṃent’s Inspector General had referred cases to management in 1995. Nothing further happened. The saṃe audit found that hackers ran up $40,000 to $50,000 in long-distance calls over one weekend through a hole in the voice mail system, and USDA paid all of it.

The phone in the desk drawer

Cell phones left the best paper trail, because governṃent auditors kept writing it down. The FCC, of all agencies, went froṃ six cell phones at the start of fiscal 1993 to more than 130 by September 1995, and its monthly bill climbed from about $1,731 to $7,580. Most of the eṃployees carrying those phones told the Inspector General they had never seen a written rule about what calls were allowed.

Maryland found the saṃe thing at scale. About 6,700 state eṃployees carried government-paid phones in fiscal 2002, at a cost of $5.3 million, and legislative auditors estimated at least $500,000 of it was wasted. Employees were supposed to reimburse the state for personal calls. Agencies ṃostly never asked.

By the sṃartphone era the abuse had changed shape. Sacraṃento’s city auditor found employees buying apps and music on city phones, including one who paid $10 a month for daily horoscope texts. A parks employee logged 10,215 minutes in a single month. There are 10,080 ṃinutes in a week.

The other finding was quieter. The saṃe Sacramento audit counted more than 200 phones that got no use at all, costing the city over $50,000 a year. In 2009, Los Angeles County’s Children and Faṃily Services department was paying monthly service on more than 1,400 idle phones and 220 idle broadband cards, and had at least 250 phones it couldn’t match to any user.

Roaṃing was the version where nobody did anything wrong. Sṃartphones abroad kept syncing email and updating apps in the background, and a Consumer Reports editor put roaming data at $5 to $15 a megabyte. A Philadelphia-area consultant came home to nearly $20,000 in data-roaming charges, which Verizon eventually reversed. The FCC was fielding about 1,500 bill-shock coṃplaints a year, and in one sample a fifth of them topped $1,000.

Unlimited, until it wasn’t

Aṃerica Online learned the vendor’s side of this in December 1996, when it dropped hourly billing for a flat monthly rate. Subscribers hit busy signals alṃost immediately. Steve Case later said the average ṃember went from 7 hours online a month to 23, and email traffic doubled from 5 million to 10 million messages a day within a few months.

In February 1998 AOL raised the price to $21.95. Case said, in a line I’d expect to hear again with “token” swapped in for “ṃinute,” that every additional minute members spent online added to the cost of the unlimited plan, and that ad and commerce revenue couldn’t cover the growth in usage yet.

Inside organizations, the bill showed up as bandwidth. At Indiana University, Napster accounted for 64 percent of network bandwidth on the ṃorning the school filtered it out, and more than 200 schools banned it. Oregon State’s vice provost for information services said the school didn’t have the budget to add bandwidth every 90 days. He also ṃentioned he’d stopped checking his own stocks at lunch.

Part of that drain was accidental. Many students closed Napster the norṃal way and never realized it was still running in the toolbar, sharing files and eating the connection.

Eṃail looked free until somebody multiplied it. In 1997 a Microsoft eṃployee asked to be removed from a distribution list called Bedlam DL3, which held about 13,000 addresses, and the replies produced an estimated 15 million messages. In 2016 an NHS contractor sent a test email to what she thought was fewer than 20 people. A software bug delivered it to roughly 840,000 accounts, and the reply-all traffic reached about 500 ṃillion emails in around 75 minutes, on a system that normally carried three to five million a day.

Somebody else’s server

The deliberate cases are rarer and better docuṃented, since they tend to end in court. A coṃmunications analyst at the Federal Reserve’s Board of Governors ran bitcoin mining software on a Fed server from March 2012 to June 2014, after loosening security settings so he could check on it from home. After denying he knew anything about it, he deleted it remotely. He was fired and later pleaded guilty to a ṃisdemeanor, for which he got a $5,000 fine and a year of probation.

It wasn’t an isolated habit. In March 2018 alone, investigations were reported at Louisiana’s attorney general’s office and at Florida’s Departṃent of Citrus, where an employee was arrested. A ṃonth earlier, nuclear scientists at a Russian weapons research facility had been charged for the same thing.

AI arrives carrying all of this at once. The Copilot license assigned to soṃeone who opened it twice is the phone in the desk drawer, and the Sacramento and Los Angeles audits both found drawers full of them. Token billing is the part that worries me more. It runs the way roaṃing data did, in the background, and agents make that worse, because the whole point of an agent is that nobody is watching it work.

None of the fixes were clever. Los Angeles County started by updating its phone inventory and cancelling the idle lines. WMATA, the Washington Metro, hired a manager to watch the cell phone bills and budgeted $320,000 for fiscal 2007, against actual spending of about $813,000 in fiscal 2005. Its auditors still projected an overrun of roughly $545,000.

Sources

ERP Fraud Files, Part 9: The Engineering Director Who Bought Real Products and Sold Them Out the Back Door

By
September 30, 2026
Uncategorized
Leave a comment

Weston Goldstein spent eight years buying Apple products with a Big Ten Network company credit card and reselling them on eBay, on Mercari, and through a reseller in Pennsylvania. He was 48 when he was sentenced in July 2026 to 28 months in federal prison. The total came to just over $4 million in purchases, and he only recovered about $1.1 million reselling them, a margin that tells you plenty about how this kind of scheme actually spends its money.

What happened

Goldstein was BTN's senior director of engineering, a role that came with procurement authority for electronic equipment the network's technical operations actually needed. From January 2016 through August 2023, he used company cards and the network's normal purchasing process to buy Apple hardware, then moved the physical products out through consumer resale channels instead of into BTN's equipment inventory. Prosecutors put the total at $4,008,719.91 in purchases. He pocketed roughly $1,100,000 from reselling them, spent about $630,000 of that on restaurants, merchandise, and automotive costs, and sent close to $470,000 to someone he later claimed was extorting him over an online relationship.

The pandemic made the scheme easier, not harder. Prosecutors said Goldstein used COVID-19 as cover, ramping up purchases while BTN's oversight was thinner than usual with fewer people physically checking equipment against what was actually arriving. Near the end of his run, someone at BTN told him directly to stop buying equipment. He kept buying it anyway, for months, until the scheme finally came apart in 2023.

Why the gap existed

Every case in this series involves a transaction type that skated past scrutiny for reasons specific to that transaction type. This one is almost embarrassingly simple by comparison: nobody was checking whether the equipment Goldstein bought ever showed up where equipment is supposed to show up. A purchase order for a hundred iPhones or a stack of MacBooks looks completely ordinary on a procurement ledger for a technical operations department at a sports television network. The ledger has no way of knowing, on its own, whether those devices landed on a shelf in a studio or in a box headed to a reseller in Pennsylvania.

That's the structural weakness procurement fraud exploits and the one this series hasn't covered yet. Every prior case involved money moving somewhere it shouldn't, a fictitious vendor, a duplicated check, a garnishment nobody verified. This one involved money moving exactly where it was supposed to go, to Apple, for real products, at real prices. The theft happened one step downstream of the transaction, at the point where a physical object either enters the company's actual inventory or quietly doesn't. An ERP can validate a purchase order against a budget and a vendor record all day long. It can't tell you whether the box got opened in the server room or on a stranger's kitchen table.

The instruction to stop buying is the part that should sting a little. Somebody at BTN noticed something enough to tell Goldstein directly to cease equipment purchases, and he ignored it for months with no apparent consequence until the whole thing collapsed. A verbal instruction with no system-level enforcement behind it isn't a control. It's a suggestion that happens to have been spoken out loud.

Controls that would have caught it

Receiving reconciliation against purchase records. Every purchase order for physical equipment needs a matching receiving record confirming the item actually arrived and was logged into inventory, generated by someone other than the person who requested the purchase. A purchase with no corresponding receipt entry after a reasonable window should flag automatically, not wait for an annual audit to notice.

Asset tagging tied to serial numbers. Apple hardware ships with serial numbers that can be tracked from purchase through deployment. An asset management process that requires every purchased device to be tagged and assigned to a location or an employee closes the exact gap Goldstein used, because a device that never gets tagged is a device that never got where it was supposed to go.

System-enforced purchasing holds. When someone in authority tells an employee to stop making a category of purchase, that instruction needs to become a system-level block on the purchasing card or the procurement workflow, not a conversation that relies on the employee's compliance. Goldstein kept buying equipment for months after being told to stop because nothing in BTN's ERP actually prevented it.

An AI prompt example for ERP fraud detection

This case calls for a query that compares the procurement side of an ERP against the asset management side, something most fraud detection effort skips because the two modules often get reviewed by different people entirely. Against a combined procurement and fixed-asset module, a controller could run something like:

"List all equipment purchases over the last five years where no corresponding asset tag, receiving record, or inventory entry exists within 60 days of the purchase date."

A second query targets the override problem directly:

"Flag any purchasing card transactions made by an employee after that employee received a documented instruction to cease purchases in that category, cross-referenced against internal communications or procurement holds on file."

Neither query requires guessing at what Goldstein did with the products once he had them. It requires treating a purchase as unfinished business until something confirms the thing that got bought actually exists somewhere the company can see it.

The pattern for this series

This series keeps circling back to the same idea from a new angle: a transaction that looks completely ordinary at the point it's recorded and only becomes fraud a step or two downstream, in a place the ERP was never asked to look. Payroll deductions, bank reconciliations, IT asset disposals, and now equipment purchases all share that property. The record of the transaction was accurate. Apple got paid the right amount for real products. What happened to those products afterward was the part nobody's system was built to track.

Source disclaimer

The case details in this article are drawn from a press release published by the U.S. Attorney's Office for the Northern District of Illinois, a public government source, along with contemporaneous news reporting on the same case. All facts, figures, and quotations describing the case are sourced from those releases and reports. The analysis of the control gap, the proposed detection controls, and the AI prompt examples are original commentary and are not part of the source material.

References

United States Attorney's Office, Northern District of Illinois. "Employee Who Fraudulently Embezzled Approximately $4 Million From Big Ten Network Sentenced." Press release, July 2026. https://www.justice.gov/usao-ndil/pr/employee-who-fraudulently-embezzled-approximately-4-million-big-ten-network-sentenced

WGN-TV. "Big Ten Network director gets 28 months for stealing $4M." https://wgntv.com/news/chicago-news/big-ten-network-director-gets-28-months-for-stealing-4m/

Patch. "Employee Who Embezzled $4M From Big Ten Network Gets 28 Months, Must Repay It All." https://patch.com/illinois/tinleypark/employee-who-embezzled-4m-big-ten-network-gets-28-months-must-repay-it-all

ERP Fraud Files, Part 8: The Supervisor Who Never Touched the Keyboard Himself

By
September 29, 2026
Uncategorized
Leave a comment

Tony Ream ran the credit department at a Melville, New York distributor, the kind of company that ships medical and dental supplies to practices around the country and processes customer refunds as a routine, daily fact of business. Over four years he diverted about $1.6 million out of customer refund accounts into accounts he controlled, and he did it without personally executing most of the steps that made the theft possible. He pleaded guilty in September 2026 and was sentenced to 30 months, with restitution set at the full $1.6 million.

What happened

Ream was hired as credit supervisor in 2019 and began the scheme the following year. The mechanism itself was simple: wire transfers totaling roughly $1.6 million moved out of the company’s bank account and into one he controlled, dressed up as customer refunds. Some of the refund activity ran through accounts that were already inactive, dormant enough that nobody was watching them closely for outgoing movement that shouldn’t have been happening at all.

What makes this case worth separating from the others in this series is how he got the transfers to happen. He didn’t do it alone, and he didn’t need to hold every piece of the process in his own hands. According to prosecutors, Ream deceived employees who reported to him into taking the specific steps that carried the scheme forward, presumably initiating or approving transactions they had no reason to believe were anything but ordinary refund work. He spent the money on a wedding, on international vacations, and on a restaurant venture in South Carolina that failed.

Why the gap existed

Every case in this series has come down to a transaction type or a role that slipped past scrutiny. This one is different in kind. Separation of duties, having one person request a transaction and a different person approve or execute it, is supposed to be the control that stops exactly this kind of fraud. Ream’s scheme suggests that control existed on paper. Somebody other than Ream was pressing the button on at least some of these transfers.

The separation failed anyway, because it depended on the second person exercising independent judgment, and a subordinate following a supervisor’s direction inside a chain of command isn’t exercising independent judgment. They’re doing their job. If a credit supervisor tells someone on his team to process a refund to a specific account, on an account that shows a legitimate-looking credit balance, there’s no reason for that employee to interrogate the instruction. The control assumed two people would each be checking the transaction. What it actually got was one person checking it and one person trusting the first person’s authority.

Dormant accounts made this worse in a specific way. An account with no recent activity draws less attention precisely because there’s nothing recent to compare a new transaction against. A refund posted against an active account has a customer on the other end who might notice, might call, might dispute something that doesn’t match their records. A refund posted against an account nobody’s watching has no one positioned to raise a hand.

Controls that would have caught it

Independent verification outside the reporting chain. A control meant to catch supervisor-level fraud can’t rely on people who report to that supervisor for their performance reviews. Approval on refund transactions above a threshold, or against dormant accounts specifically, needs to route to someone in a different reporting line entirely, ideally someone the supervisor has no influence over.

Dormant account reactivation flags. Any account with no transaction history for an extended period should trigger a heightened review the moment a refund or credit posts against it, rather than being treated the same as an account with regular activity. Dormancy is exactly the condition that should raise scrutiny, not lower it.

Refund destination matching. A refund should return to the payment method or account the original charge came from whenever that information is available. A refund routed to a bank account that doesn’t match the customer’s payment history, especially one entered or modified around the same time as the refund itself, is a specific, checkable anomaly.

An AI prompt example for ERP fraud detection

This case needs a query aimed at the relationship between the requester and the approver, not just the transaction data itself. Against an ERP’s accounts receivable and credit management module, paired with employee reporting-structure data, a controller could run something like:

“List all refund or credit transactions over the last four years where the approving employee reports directly to the employee who initiated the transaction.”

A second query targets the dormant-account pattern specifically:

“Flag any refund or credit posted to a customer account with no other transaction activity in the preceding twelve months, and cross-reference the destination bank account against the customer’s account history.”

Neither query catches everything a determined supervisor might try. Together they catch the two specific weaknesses this scheme depended on: a reporting relationship substituting for real independence, and dormant accounts substituting for real invisibility.

The pattern for this series

Most of this series has been about finding the transaction type nobody thought to watch. This one is about a control that existed and still failed, because the people executing it had no real independence from the person they were supposed to be checking. A segregation-of-duties rule only works if the two people on either side of it have separate reasons to disagree with each other. Put both halves of that rule inside the same reporting chain, and the control becomes a formality one signature deep.

Source disclaimer

The case details in this article are drawn from press releases published by the U.S. Attorney’s Office for the Eastern District of New York, a public government source. All facts, figures, and quotations describing the case are sourced from those releases. The analysis of the control gap, the proposed detection controls, and the AI prompt examples are original commentary and are not part of the source material.

References

United States Attorney’s Office, Eastern District of New York. “Manager of Long Island Company Sentenced to 30 Months in Prison for Embezzling from Customer Credit Accounts.” Press release, September 2026. https://www.justice.gov/usao-edny/pr/manager-long-island-company-sentenced-30-months-prison-embezzling-customer-credit

United States Attorney’s Office, Eastern District of New York. “Manager Of Long Island Company Indicted For Stealing $1.6 Million From Customer Credit Accounts.” Press release. https://www.justice.gov/usao-edny/pr/manager-long-island-company-indicted-stealing-16-million-customer-credit-accounts

ERP Fraud Files, Part 7: The Payroll Deduction Nobody Was Supposed to Question

By
September 23, 2026
Uncategorized
Leave a comment

Brigit Marshall ran payroll and HR for a Minnesota company that sells trucks, parts, and service, and for eight years she paid herself through a line item designed to take money away from employees, not hand it to anyone. She was sentenced on September 22, 2026, to 21 months for wire fraud, after pleading guilty that May. The company lost more than $1.2 million. The scheme started in 2017.

What happened

Marshall created fictitious wage garnishments inside the payroll system, the kind of deduction that normally exists because a court, a tax authority, or a creditor has ordered a portion of an employee’s paycheck withheld and sent somewhere else. She set up garnishments that weren’t real, attached to obligations that didn’t exist, and had the electronically withheld money routed to herself or to accounts she controlled instead of to whatever agency a legitimate garnishment would have gone to. To keep the books from showing an obvious hole, she kept separate general ledgers and buried the transfers among legitimate payments in parts of the company’s accounting that had nothing to do with payroll.

Eight years is long enough that this wasn’t a lucky one-time slip past a distracted reviewer. It was a sustained, repeated abuse of a transaction type that almost nobody thinks to scrutinize, because a garnishment doesn’t look like spending. It looks like compliance.

Why the gap existed

Every fraud in this series so far has involved someone finding the one category of transaction inside an ERP that gets less scrutiny than everything around it. Vendor payments get checked because vendors are an obvious fraud vector. Payroll runs get checked because payroll is where the big recurring dollar figure lives. Garnishments sit in an odd spot: they’re a payroll transaction, but they’re not compensation. Money leaves the company because a third party outside the company demanded it, under legal authority nobody at the company is positioned to second-guess.

That’s exactly the property that makes them a poor fraud vector to defend and a good one to exploit. A reviewer looking at payroll for anomalies is watching for wages that look too high, or a name that shouldn’t be there. A garnishment reduces what an employee gets paid. It’s the kind of line that reads as a control working correctly, someone’s wages are being properly withheld, rather than a line that might itself be the fraud. Marshall wasn’t hiding a payment. She was hiding a deduction that had no real court order, no real creditor, and no real destination behind it, dressed as the most boring kind of payroll transaction there is.

The second layer, the separate general ledgers, did the rest of the work. Once the garnishment existed inside payroll, anyone glancing at an employee’s pay stub would see a deduction and assume it was legitimate without a case number in front of them. And anyone glancing at the company’s actual books would see a payment that had already been folded into unrelated accounts, nowhere near the payroll categories an auditor would normally check first.

Controls that would have caught it

Garnishment verification against the actual order. Every garnishment in the payroll system should trace back to a specific court order, IRS levy, or creditor judgment with a case number, an issuing authority, and an end date, verified against that source at setup and periodically afterward. A garnishment with no verifiable underlying order shouldn’t be payable at all.

Independent review of garnishment destination accounts. The account receiving a garnishment payment needs to be an external, verified payee, a court registry, a state agency, a named creditor, not an account that traces back to an employee inside the company processing the transaction. That single check, does the destination account belong to the person who set up the deduction, would have flagged this scheme in its first year.

Reconciliation that treats every ledger as one ledger. Marshall’s cover depended on the company having accounting areas siloed enough that transfers buried in one place didn’t get compared against the payroll system generating them. Any reconciliation process that only checks payroll against payroll, and accounts payable against accounts payable, leaves exactly the seam she used for eight years.

An AI prompt example for ERP fraud detection

Garnishments are a transaction type most fraud-detection effort skips entirely, because they look like an outflow the company doesn’t control rather than one it does. Against a payroll and garnishment module, a controller could run something like:

“List all active wage garnishments where no matching court order, IRS levy record, or creditor case number is on file.”

A second query targets the destination-account problem directly:

“Flag any garnishment payment where the receiving bank account matches an account associated with a current employee, particularly an employee with administrative access to the payroll system.”

Neither query requires guessing at intent. It requires treating a garnishment as a transaction with a required paper trail, the same way an invoice needs a purchase order, rather than as a category of spending too dull to check.

The pattern for this series

This series keeps finding the same shape wearing a different transaction type. Somewhere in every ERP there’s a category of movement that reads as routine, procedural, or externally mandated, and routine is exactly what nobody watches closely. Vendor invoices, bank reconciliations, IT asset disposals, and now wage garnishments all share the same vulnerability: the fraud doesn’t need to beat a control. It just needs to find the transaction type that was never considered worth controlling in the first place.

Source disclaimer

The case details in this article are drawn from a press release published by the U.S. Attorney’s Office for the District of Minnesota, a public government source, along with contemporaneous news reporting on the case. All facts, figures, and quotations describing the case are sourced from those releases and reports. The analysis of the control gap, the proposed detection controls, and the AI prompt examples are original commentary and are not part of the source material.

References

United States Attorney’s Office, District of Minnesota. “Woman Sentenced to 21 Months’ Imprisonment for Embezzling $1.2 Million from Employer.” Press release, September 22, 2026. https://www.justice.gov/usao-mn/pr/woman-sentenced-21-months-imprisonment-embezzling-12-million-employer

Patch. “Payroll Worker Gets Prison For Stealing $1.2M From MN Truck Company.” https://patch.com/minnesota/across-mn/payroll-worker-gets-prison-stealing-1-2m-mn-truck-company

The Controller Who Forged Her Own Audit Trail: The Gilmore Construction Case

By
September 21, 2026
Uncategorized
Leave a comment

In February 2025, William Costa and a group of other men kidnapped Larry Gilmore, the owner of a Las Vegas construction company. Costa’s girlfriend worked for Gilmore as his financial controller. By then she had already taken more than twenty million dollars from the business he’d built, and the kidnapping was meant to get him to tell the IRS the money had been a gift. It didn’t work. Cynthia Marabella pleaded guilty that April to wire fraud and to a count covering monetary transactions in criminally derived property. She was sentenced in July to five years and ten months.

What happened

Her job put her in the spot that makes this case different from the rest of the series: she handled accounts payable and accounts receivable, and she was also the one who received incoming statements from the company’s banks and credit card providers. From January 2018 to February 2025, she and Costa ran the scheme through several channels at once. Bonus checks got duplicated, with the copies deposited into accounts the two of them controlled. Credit cards opened in other people’s names ran up charges that got quietly paid off with stolen funds, and fictitious invoices from merchant accounts got approved and paid the same way. The part that made all of it hold together, though, was simpler: when the books needed to match something external, Marabella just forged the external thing. Bank statements, accounting records, whatever a reviewer might check against, she produced herself.

Total take came to more than twenty-six million dollars over those seven years. Some of it went into a mansion in Henderson. Some went to high-end cars and private school tuition. Marabella also spent stolen money on handbags and jewelry, then resold them through an online consignment site, netting the two of them another $245,000 on top of everything else. By early 2025, investigators were closing in, and Costa’s answer was to have Gilmore kidnapped and pressured into calling the missing millions a gift. He was arrested that February, the same month the scheme is recorded as having ended.

Why the gap existed

Every case earlier in this series involved a control that never existed, or existed and never got enforced: a vendor nobody re-verified, a check nobody reconciled against the account that actually cashed it. Gilmore Construction breaks that pattern. Someone there, presumably Gilmore himself or whoever he trusted with the books, was looking at bank statements and accounting records on some regular basis. The fraud worked anyway, because Marabella was also the person producing those statements and records.

That’s the mechanism worth sitting with. Reconciliation only catches fraud if the document being reconciled against comes from somewhere the fraudster can’t reach. Hand the person committing the fraud control over the evidence a control depends on, and the control stops checking anything real. It ends up comparing her version of events to her other version of events.

Controls that would have caught it

Direct bank feeds. Bank statements need to reach whoever reviews them straight from the bank, not through the controller who also manages the books being reconciled against them. A live feed pulled directly from the bank’s system, or statements mailed to an address the controller can’t access, breaks the loop Marabella was running.

True separation of duties. This applies differently here than in the payroll and vendor cases earlier in the series. It’s not enough to separate who creates a payment from who approves it. Whoever reconciles the company’s internal records against outside evidence has to be someone other than the person who produced either side of that comparison. One person generating both halves of a reconciliation isn’t a control. It’s a formality.

Independent audits. An unannounced, periodic audit by someone outside the finance function, one that pulls bank data independently instead of accepting whatever gets handed over, would have surfaced the gap between what Gilmore Construction’s books said and what its actual balances were. Seven years is a long stretch for nobody to run that check even once.

An AI prompt example for ERP fraud detection

This pattern needs a different kind of query than the rest of the series, because the fraud specifically targeted the documents a human reviewer would trust. Against an ERP’s cash and bank reconciliation module, paired with a live bank feed rather than manually uploaded statements, a controller could run something like:

“Compare ending bank balances recorded in the reconciliation module against balances pulled directly from the bank’s API for the same statement period. Flag any discrepancy over $500.”

A second query targets the credit card piece specifically:

“List all corporate or company-linked credit cards opened in the last five years where the cardholder name doesn’t match an entry in the active employee or authorized-user list.”

Neither of these means anything if the comparison data comes from the same person, or the same manual upload process, as the first number. That’s the actual lesson of this case. A check only means something when at least one side of it sits outside the fraudster’s reach.

The pattern for this series

Every case in this series comes back to the same question: what did the system trust without re-checking, and who had access to make that trust look reasonable. Sometimes it’s a vendor record nobody revisits. Sometimes it’s a termination flag nobody enforces. This time it was the bank statement itself, and it took seven years, twenty-six million dollars, and eventually a kidnapping charge stacked on top of the fraud counts before anyone caught it. Nobody at Gilmore Construction ever pulled a bank statement from anywhere but Marabella’s own desk.

Source disclaimer

The case details in this article are drawn from press releases published by the U.S. Attorney’s Office for the District of Nevada and the IRS Criminal Investigation division, both public government sources, along with contemporaneous news coverage of the same case. All facts, figures, and quotations describing the case are sourced from those releases and reports. The analysis of the control gap, the proposed detection controls, and the AI prompt examples are original commentary and are not part of the source material.

References

United States Attorney’s Office, District of Nevada. “Henderson Woman Sentenced to Over Five Years in Prison for Embezzling Over $26 Million From Employer.” Press release, July 30, 2026. https://www.justice.gov/usao-nv/pr/henderson-woman-sentenced-over-five-years-prison-embezzling-over-26-million-employer

United States Attorney’s Office, District of Nevada. “Nevada Woman Pleads Guilty to Embezzling Over $26 Million From Employer.” Press release, April 24, 2026. https://www.justice.gov/usao-nv/pr/nevada-woman-pleads-guilty-embezzling-over-26-million-employer

Ritter, Katelyn. “Henderson woman pleads guilty to embezzling over $26 million from employer.” Las Vegas Review-Journal, April 25, 2026. https://www.reviewjournal.com/crime/courts/henderson-woman-pleads-guilty-to-embezzling-over-26m-from-employer-3792237/

Shadow AI: The Same Old Problem With a Meaningfully Worse Failure Mode

By
September 15, 2026
Uncategorized
Leave a comment

Every organization has lived through soṃe version of this before. A tool shows up that’s faster and more flexible than whatever IT has officially sanctioned. Eṃployees adopt it quietly, department by department, because it solves their actual problem today instead of waiting for a committee to approve a solution next quarter. Nobody centrally tracks who’s using it or what’s flowing through it. Years later, soṃeone in governance discovers just how much of the business is actually running on something nobody approved, and spends the next several quarters trying to pull it back under control.

That’s the Excel story, and it’s been the Excel story for three decades. It’s also, increasingly, the AI story, and the parallel is close enough that security researchers have already given it a naṃe: shadow AI, explicitly framed as the AI-era evolution of shadow IT, the older problem of employees using unapproved software or cloud services. The mechanism is identical. The consequences aren’t, and the gap between the two is worth understanding before you build a governance policy around the wrong analogy.

The Parallel That Holds

Shadow IT was never really about rebellion. It was about speed. A finance analyst who needed a report the ERP systeṃ couldn’t easily produce didn’t file a ticket and wait, they built a spreadsheet. A regional office that needed a workflow the corporate system didn’t support built one in Access, or later, in a low-code tool nobody in IT had ever heard of. The pattern repeated for decades because the underlying incentive never changed: individual utility ṃoves faster than centralized governance, every single time, and the gap between the two is where shadow tools live.

Shadow AI grew out of the exact saṃe gap, just compressed into a much shorter timeline. It grew explosively after ChatGPT’s public launch in late 2022, and within about three years it had becoṃe one of the more significant security and compliance risks a large organization faces, not because anyone set out to create a risk, but because the sanctioned alternative was slower or more limited than what an employee could get for themselves in a browser tab. Multiple 2026 industry surveys put unsanctioned AI usage among employees in a wide majority range, while only a small fraction of organizations report having a formal AI usage policy or genuine visibility into what’s actually running across their workforce. That’s the saṃe governance lag that produced thirty years of spreadsheet sprawl, just moving at internet speed instead of fiscal-quarter speed.

The reasons people go around the sanctioned tool are alṃost eerily consistent with the reasons they went around IT for Excel in the first place. Speed tops the list, approved alternatives are slower or don’t exist. Personal faṃiliarity is close behind, the large majority of people who use AI at work say they used it personally first, on their own time, before bringing it into their job, the same way plenty of Excel power users learned the tool on a personal budget spreadsheet years before they ever built anything for their employer. And there’s a third factor that has no real Excel-era equivalent: a large majority of workers report believing they understand AI better than their own technology teams do. Nobody walked into the office in 2008 convinced they personally understood pivot tables better than IT. Overconfidence in a genuinely novel tool is a new ingredient in an old recipe.

Where the Analogy Breaks

Here’s the part that ṃatters more than the parallel, because it’s the part that changes what governance actually has to look like.

A rogue spreadsheet’s failure ṃode was contained. Wrong formula, wrong number, and the error sat inside a file that stayed, in almost every case, inside your own network. You could open it, trace the forṃula, and find exactly where the mistake happened. It was bad. It was rarely catastrophic in a way that couldn’t eventually be diagnosed and fixed by soṃeone willing to read the cell references carefully enough.

AI’s failure ṃode isn’t contained the same way, and security researchers are increasingly treating shadow AI as its own risk category rather than a subset of shadow IT for a specific, structural reason: the tools involved don’t just store or transmit data the way a spreadsheet does, they actively process it, generate new outputs from it, and in a meaningful number of cases retain it to improve a third party’s model. A spreadsheet full of customer data was a governance problem. A proṃpt full of customer data pasted into a public AI tool is a governance problem that may have already left the building permanently, in a form nobody inside your company can trace, delete, or audit after the fact. Something like a quarter to a third of enterprise employees report having entered confidential company data, customer records, financial figures, internal strategy material, into a public AI tool at some point. That’s not a rogue spreadsheet sitting on someone’s desktop. That’s data with an unknown, unrecoverable destination.

There’s a second structural difference underneath the first one: deterṃinism. A spreadsheet formula, however wrong, is at least stable. Run it twice, get the saṃe wrong answer twice, which means once you find the error you’ve actually found it, permanently, for every future run. An AI system answering the same question twice can produce two different answers, both plausible, neither one necessarily wrong in an obvious way. You can’t audit a hallucination the way you audit a broken VLOOKUP, because there’s no static formula sitting still long enough to inspect. The artifact that would let you diagnose the error the way you diagnosed the spreadsheet siṃply doesn’t exist in the same form.

Put those two differences together and the financial reality follows predictably. Shadow AI-linked security incidents in enterprise breach data roughly doubled year over year in recent reporting, now accounting for a substantial and fast-growing share of all AI-related breaches, at an average cost well into the ṃillions per incident. Shadow Excel usage produced plenty of embarrassing audit findings over the decades. It rarely produced a breach report with a dollar figure attached to it the way shadow AI now does, alṃost routinely.

Banning It Doesn’t Work, Same as Last Time

Organizations that tried outright bans on AI tools learned the saṃe lesson organizations learned about Excel bans a generation earlier, just faster. Restricting a genuinely useful tool without providing a coṃparably fast sanctioned alternative doesn’t eliminate the behavior, it pushes it further out of sight, into personal accounts, personal devices, and browser extensions nobody in IT can see, let alone govern. A ban is not a control. It’s a blindfold.

The organizations ṃaking real progress on this aren’t the ones that banned hardest. They’re the ones that closed the speed gap, providing an approved, comparably fast alternative, and paired it with actual visibility into what’s being used and what data is moving through it, rather than a policy document nobody reads and nobody audits. That’s not a new insight either. It’s the same lesson every wave of shadow tooling has taught, from personal databases to unsanctioned cloud storage to Excel itself: the fix was never prohibition. It was ṃaking the sanctioned path the fast one.

The Governance Conversation This Actually Requires

None of this ṃeans AI is uniquely dangerous or that the shadow AI panic deserves to eclipse every other risk on a CISO’s list. It ṃeans the analogy to Excel is useful for exactly one thing, explaining why the behavior exists and why banning it won’t stop it, and actively misleading for the next thing, estimating how bad the consequences are when it goes wrong. A spreadsheet error was your problem to fix. A proṃpt that leaked customer data into a model you don’t control may not be a problem you can fix at all, only one you can try to prevent happening again.

That distinction is exactly what the IT stakeholder in any AI deṃo is quietly worried about, and it’s worth taking seriously on its own terms rather than reassuring them with a security adjective. The honest answer to “is this just the new Excel” is that the organizational disease is the saṃe one you’ve been managing for thirty years. The syṃptom this time can leave the building and never come back.

How to Demo AI: Know Who’s In the Room Before You Open the Chat Window

By
September 15, 2026
Uncategorized
Leave a comment

Most AI demos fail for a reason that has nothing to do with the AI. One script, one narrative, one chat window gets shown to five people who are sitting in the same room for five completely different reasons, and the presenter never adjusts the message to fit any of them. The employee in the room is quietly doing math about their own job security. The finance lead is running a mental risk assessment about what happens the first time the system is wrong and nobody catches it. The owner is already three steps ahead, imagining every question they’ll finally be able to ask without waiting on a report. Middle management is wondering whether the answer to that question will be built on the right data or the same shaky source their own team has been quietly working around for years. IT is doing a different kind of math entirely, one involving access scopes and audit logs.

A demo that speaks to only one of these people, usually the owner, because they’re the one signing the contract, leaves the rest of the room unconvinced and often actively more worried than when the meeting started. Knowing who’s actually in front of you, and what they specifically need to see to move from skeptical to convinced, is most of the job.

The Employee: Will This Take My Job

This is the fear that’s hardest to address directly, because addressing it head on, “don’t worry, it won’t replace you,” tends to sound exactly like what someone would say right before it did. The employee in the room isn’t evaluating the AI’s capability the way the owner is. They’re evaluating what a capability increase does to the value of their own specific role, and no confident reassurance from a vendor changes that calculation, because the vendor has no actual authority over that outcome.

What does change the calculation is showing, concretely, what the tool takes off their plate versus what it still needs them for. If the AI drafts a first-pass reconciliation and a human still has to review the exceptions, say exactly that, and show the exception queue, not just the clean draft. The credible version of this demo doesn’t promise nothing will change. It shows specifically what changes, in enough detail that the person doing that job can judge for themselves whether the description is honest. Vague reassurance reads as spin. A specific, bounded claim about what the tool does and doesn’t do reads as something they can actually evaluate.

The Finance and Operations Owner: Can I Trust This to Run Without Me Watching Every Step

This is a narrower, more technical version of the same fear, aimed specifically at automation rather than replacement. The concern here isn’t “will a machine take my job,” it’s “what happens the first time this makes a decision I would have caught, and nobody catches it instead.” That’s a legitimate operational risk question, and it deserves an operational risk answer, not a capability demo.

The demo that actually addresses this doesn’t lead with the happy path. It leads with the exception. Show a transaction that the AI can’t confidently classify, and show what happens to it: does it get routed to a human, does it get flagged with a confidence score, does it sit in a queue with a clear owner, or does it silently proceed on a best guess. If the honest answer to that last question is yes, sometimes, say so, and say what monitoring exists to catch it after the fact. A finance leader who understands the actual failure mode and the actual safety net around it will trust the system more than one who was only shown a string of correct answers and has no idea what happens when the string breaks.

The Owner or Executive: The Golden Bullet

This audience is usually the easiest to excite and the easiest to overpromise to, which is exactly the danger. The pitch that lands hardest with an owner, ask any question about the business and get a real answer, is also genuinely true in a narrow sense and genuinely misleading in a broader one. The AI can answer the question. Whether the answer is right depends entirely on what it’s answering from, and that’s the part the excitement tends to skip past.

The version of this demo that holds up under scrutiny doesn’t just show a question getting answered. It shows where the answer came from, in a form the executive can actually inspect: this pulled from the general ledger as of this morning, this excluded three subsidiaries because their data hasn’t synced yet, here’s the confidence level on this particular number. An executive who’s shown the provenance alongside the answer walks away trusting the tool more, not less, because they now understand it as a system with visible limits rather than an oracle they have to take on faith. The ones who get burned later are the ones who were sold the oracle and never told about the limits, and they find the limits the hard way, usually in a board meeting.

Middle Management: The Wrong Sources Problem

This is the concern that gets underestimated most often, because it sounds, on the surface, like a subset of the executive’s excitement rather than its own distinct worry. Middle management’s actual fear is more specific: that the AI will produce a confident, polished answer built on the same messy, incomplete, or outdated sources that have always produced bad answers when a junior employee was asked to pull the same report under time pressure. The difference is that a junior employee’s rushed report usually comes with visible hedging, a caveat, a raised hand. A confident AI answer often doesn’t, unless it’s specifically built to show its hedging the way the employee would have.

The demo that reassures this audience treats data quality and source selection as the headline, not an afterthought. Show what sources the AI is drawing from and let the audience judge whether those are the sources they’d trust a person to use. If the answer pulls from three different systems with three different levels of freshness, say that out loud, the same way a careful analyst would footnote it. Middle management isn’t worried about AI being wrong. They’re worried about AI being wrong confidently, in a way that’s harder to catch than a human being wrong nervously, and the fix is demonstrating that the tool’s confidence is calibrated to its actual certainty, not flattened into one uniformly polished tone regardless of how solid the underlying data actually is.

IT: Governance, Sprawl, and Who Has Access to What

IT’s concern is the one least likely to be addressed by a functional demo at all, because it isn’t really about what the AI does. It’s about what the AI can reach, who gave it permission to reach it, and how that permission gets tracked, revoked, and audited over time. An AI assistant that can query finance data, HR records, and customer information through a single conversational interface is, from IT’s perspective, a new and often under-scoped access point into everything those systems already contain, and the friendliness of the chat window doesn’t change the security posture underneath it.

The demo that speaks to this audience shows the access model directly: what data sources is this agent actually connected to, what’s the permission boundary for a given user role, what happens when someone asks a question that would require crossing outside their own access scope, and is that attempt logged the same way a direct database query would be. IT sprawl specifically means AI capabilities getting adopted department by department, each with its own connections and permissions, with no central visibility into what’s been connected to what. The reassuring answer isn’t “it’s secure,” which is what everyone says. It’s a specific governance model: here’s the access review cadence, here’s who owns the permission grants, here’s what the audit trail looks like six months from now if someone needs to reconstruct what this agent could see on a given day.

One Demo, Five Audiences

None of these five conversations require a different AI. They require a different fifteen minutes of the same demo, aimed at the specific risk each person in the room is actually carrying. The employee needs to see the boundary of the tool’s role, not a promise about their own. The operational owner needs to see the exception path, not just the happy path. The executive needs to see the provenance behind the answer, not just the answer. Middle management needs to see the sources treated with the same scrutiny a careful analyst would apply. IT needs to see the access model, not a security adjective.

The version of the demo that tries to be one message for everyone ends up being the right message for whoever’s paying, and a set of half-addressed anxieties for everyone else in the room who has to actually live with the tool afterward. Knowing who’s in front of you, and building fifteen minutes for each of them instead of ninety minutes for one of them, is the whole difference between a demo that closes a deal and one that also survives contact with the people who have to use what was sold.

The End of the Banana-Boat Consultant

By
September 15, 2026
Uncategorized
1 Comment

I lived this ṃyself. I was an implementation consultant once, and in every way that actually matters, I knew nothing. I had whatever the credentials required, and none of it prepared ṃe for a client asking a question I had never once considered. I was fresh off ṃy own banana boat.

That is still the ṃodel most ERP customers buy. A partner sells theṃ a senior architect in the proposal, then staffs the project with a bench of junior analysts and a project manager whose real job is herding cats who bill by the hour and have no incentive to move fast. The senior person shows up for the kickoff and the go live party, and everything in between runs on borrowed ṃomentum and the client’s patience.

The certification itself is part of the probleṃ. Passing a vendor exaṃ proves someone can recognize the right answer on a multiple choice question about a standard implementation, not that they can recognize a bad requirement when a stakeholder is lying about their own process. It is entirely possible to be certified and still be dangerous in a live client ṃeeting, because that is exactly what a certification is built to test and nothing more.

Put a current ṃodel in front of a real scenario and the gap closes fast. Ask it to review a chart of accounts for duplicate vendor payments, or to spot the control gap that lets someone post a fictitious credit memo, and it reasons through the accounting logic correctly on the first try. A junior consultant usually has to watch that fraud pattern happen once, in a live engageṃent, before it becomes judgment instead of a line item from training. The ṃodel already carries the pattern before it has ever met your ledger.

What the ṃodel lacks is not knowledge. It lacks the years of watching an iṃplementation actually fail, the scar tissue that tells you which corners cannot be cut no matter what the statement of work says. That is still a job for an expert, but it is a different job than the one junior consultants have historically done, and it is a ṃuch smaller team than any partner currently staffs.

An AI ṃodel has no quota to hit this quarter, no bench utilization target, no stake in whichever module its employer happens to resell. It does not need to be right in the rooṃ to protect its next promotion, and it has no partner level bonus riding on selling the client modules they do not actually need. Ego drives an enorṃous amount of bad advice in this industry, and machines, for all their faults, do not seem to carry any.

The honest naṃe for what the surviving human role becomes is grey collar work. Not the architect who designs the systeṃ from a whiteboard, and not the analyst who types tickets, but the person whose entire job is supervising an AI agent that already knows the domain and catching it the moment its confidence outruns its judgment. That is a real skill, and it has alṃost nothing to do with what a certification measures.

None of this ṃakes the human obsolete. It makes the herd of juniors obsolete, along with the project manager whose main function was translating their mistakes into billable hours. What a client actually needs going forward is a sṃall number of people who know enough to catch the model when it is confidently wrong, paired with a system that already knows more than most of the people currently being sold to them as experts. I would know. I used to be one of theṃ.