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

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

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

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/

Sheila Kaye Jameson was a logistics analyst at EnerSys Corporation in Reading, Pennsylvania, not an executive, not someone with unusual authority. Over roughly eleven years she embezzled approximately $1.8 million from her employer using a company she invented herself. She was sentenced to 48 months in federal prison and ordered to pay $1,864,024 in restitution to EnerSys and its insurer, plus $256,447 in back taxes to the IRS.

What happened

Jameson created a shell corporation called Aries Consulting Group. It did no work for EnerSys. It provided no services, delivered no goods, and had no legitimate business relationship with the company at all. What it had was a name, a bank account, and a place in EnerSys’s vendor records. Jameson used her position to submit invoices from Aries Consulting to EnerSys, and EnerSys paid them, for over a decade, on the strength of nothing more than an invoice arriving from a vendor that existed in the system.

She also failed to report any of the embezzled income on her federal tax returns, which added tax fraud charges on top of the mail fraud charge she ultimately pleaded guilty to.

Why the gap existed

This case is the purest version of a problem that shows up across every entry in this series so far: a system that verifies a vendor once, at onboarding, and then trusts that vendor’s invoices indefinitely without asking whether the underlying business relationship still makes sense, or ever made sense in the first place.

Eleven years is the number that should stop anyone reading this. Not eleven months, not two years. Eleven years of invoices from a company that never did a single hour of real work, moving through an accounts payable process that had every opportunity to ask “what does Aries Consulting actually do for us” and never did.

That question doesn’t get asked because vendor verification tends to be treated as a one-time gate. Pass it once at setup, and the vendor becomes permanently trusted infrastructure. Nobody re-examines a vendor relationship that has been running smoothly for years, precisely because it has been running smoothly for years. The absence of a problem gets read as evidence there isn’t one, when it might just mean nobody has looked.

Controls that would have caught it

A recurring vendor spend review is the most direct control here: a periodic requirement that every vendor above a spend threshold be re-justified with a current description of the services being provided and evidence that those services were actually delivered. Not a renewal of a contract. An active accounting for what the money is buying.

A second, more structural control targets exactly the gap Jameson exploited: any vendor whose only interaction with the company is invoicing, with no purchase orders, no receiving records, no contract on file, and no employee outside the person who onboarded them able to describe what the vendor does, should be flagged automatically for review regardless of how long the relationship has run. Tenure should never be treated as verification.

A third control, specific to logistics and operations roles with vendor-creation authority, is separating who can create a new vendor record from who can approve payments to that vendor. Jameson’s position gave her enough reach to do both. A system where those two functions sit with different people doesn’t stop a determined employee from ever attempting fraud, but it does stop one person from running the entire scheme alone for a decade without anyone else’s decision ever touching it.

An AI prompt example for ERP fraud detection

The pattern this scheme depended on, a vendor relationship with invoices but no other supporting business activity, is exactly the kind of thing worth checking continuously rather than during an occasional audit. Against the ERP’s vendor, purchasing, and receiving data, a controller could run something like:

“List all active vendors with total payments over $50,000 in the last three years that have no associated purchase orders and no receiving or goods-receipt records on file.”

A second query targets the tenure blind spot directly:

“Flag any vendor active for more than five years whose invoicing pattern has not been reviewed or re-verified since initial onboarding.”

Neither question is hard to answer once it’s asked. The entire eleven years this scheme ran is evidence that nobody was asking it.

The pattern for this series

Every case in this series follows the same shape: what happened, what shared assumption let it run, what a properly governed ERP control looks like, and one or two concrete AI prompts that turn a periodic audit question into something that can run continuously. The goal isn’t to suggest AI replaces the underlying data governance. It’s to show what becomes possible once that governance exists and someone actually asks it the right question.

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 Pennsylvania, 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 Pennsylvania. “Corporate Employee Sentenced For Embezzlement And Tax Fraud.” Press release. https://www.justice.gov/usao-edpa/pr/corporate-employee-sentenced-embezzlement-and-tax-fraud

United States Attorney’s Office, Eastern District of Pennsylvania. “Corporate Employee Charged With Embezzlement And Tax Fraud.” Press release, June 28, 2012. https://www.justice.gov/archive/usao/pae/News/2012/June/jameson_release.htm

In 2022, a Minnesota woman was sentenced to more than nine years in federal prison for embezzling over $881,000 from a Denny’s franchisee and a family-owned construction company. What makes this case worth a second look, beyond the last article’s Randstad payroll scheme, is that the same person ran two separate fraud channels through the same underlying weakness, and neither channel needed to be sophisticated to work for five years.

What happened

As Director of Operations for MI5, Inc., Kimberly Sue Peterson-Janovec had oversight of payroll, vendor billing, and cash deposits across eight restaurant locations. She used that access two ways. First, she submitted false requests for vendor payments, creating fake email accounts to impersonate vendor employees and generate fake correspondence supporting the payments, netting roughly $336,000. Second, and separately, she manipulated the payroll system to issue herself unauthorized pay using the names of employees who no longer worked for the company, netting another $20,000. On top of that, she was held responsible for an additional $181,000 in stolen cash deposits.

Two different fraud mechanisms, one root cause. Both vendor identity and employee identity were things the system trusted once established and never re-verified.

Why one control gap produced two exploits

Most ERP fraud writeups treat vendor fraud and payroll fraud as separate problems needing separate controls. They usually are separate controls in practice, but they share the same underlying assumption: once a master record exists, whether it is a vendor or an employee, the system treats it as valid until someone actively flags it. Nobody was asking the system to continuously re-verify “is this vendor real” or “is this employee still employed” on every transaction. Both checks happened, if at all, as periodic manual review rather than a standing rule enforced on every payment run.

That is the pattern worth generalizing. A fraud scheme doesn’t need two different weaknesses to run two different exploits. It needs one weak assumption that both processes happen to share.

Controls that would have caught it

Vendor side. A governed vendor master process should treat any new vendor contact channel, especially email domains that don’t match a registered business domain, as a flag requiring secondary approval before the first payment goes out. Cross-referencing vendor contact emails against internal employee email patterns is a cheap, high-value check most ERP implementations never configure, because it isn’t a default workflow. It has to be built.

Payroll side. Every pay run should cross-check active employee status at the moment of payment, not rely on a termination flag set once in HR and assumed to propagate. In practice, this means the HR and payroll integration needs to be a hard gate, not a soft sync, so a terminated worker record cannot appear as a valid payee in any pay run regardless of when the termination was recorded relative to payroll cutoff.

Both sides. The five-year duration of this scheme is the real tell. Neither vendor payments nor payroll runs were being reviewed for anomalies as a routine, systemic process. They were being trusted because they had always been trusted.

An AI prompt example for ERP fraud detection

This is where AI-assisted review earns its place, not replacing the controls above but catching what static rules miss because nobody thought to write the rule. Using a natural-language query layer against the ERP’s vendor and payroll data, a controller could run something like:

“Compare vendor contact email domains against our employee email domain. Flag any vendor created in the last 24 months where the contact email domain is unregistered, uses a free email provider, or closely resembles an employee’s name.”

And separately:

“List all payroll disbursements in the last fiscal year paid to employee IDs with a termination date recorded in HR prior to the pay period start date.”

Neither query requires new functionality. Both require someone to think to ask the question, which is exactly what a five-year undetected scheme tells you nobody was doing. The value of an AI layer here isn’t that it catches something a human couldn’t. It’s that it makes asking the question cheap enough to do routinely instead of only after something else triggers an audit.

The pattern for this series

Every case in this series will follow the same shape: what happened, what shared assumption let it run, what a properly governed ERP control looks like, and one or two concrete AI prompts that turn a periodic audit question into something that can run continuously. The goal isn’t to suggest AI replaces the underlying data governance. It’s to show what becomes possible once that governance exists and someone actually asks it the right question.

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 coverage of the same case. All facts, figures, and quotations describing the case are sourced from those releases and reports. The analysis of the shared 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. “Kenyon Bookkeeper Sentenced to More Than 9 Years Prison for $881,000 Employer Embezzlement and Tax Fraud Scheme.” Press release. https://www.justice.gov/usao-mn/pr/kenyon-bookkeeper-sentenced-more-9-years-prison-881000-employer-embezzlement-and-tax

Walsh, Paul. “Woman who embezzled $880,000 from Denny’s franchisee, Rochester company gets 9 years.” Minnesota Star Tribune, June 2022. https://www.startribune.com/9-1-4-years-in-prison-for-woman-who-embezzled-880k-from-dennys-franchisee-rochester-company/600184577

Enterprise software has spent forty years arguing about the same question in different clothes. Should a function do one thing correctly, or should a tool be given enough authority to figure things out on its own. Agentic AI has not settled that argument. It has just given it a new vocabulary.

Look at the two ends of what is shipping right now. SAP’s Joule agents, and most of the enterprise agent catalog around them, are built narrow. Each one has a defined job, a defined sequence, and a defined set of systems it is allowed to touch. An invoice reconciliation agent reconciles invoices. It does not decide to also check vendor master data for anomalies unless that step was explicitly wired into its process. Microsoft’s Cowork points at the opposite pole. It is handed a single broad tool, effectively full reach into a Dynamics 365 Finance and Operations environment, and told to figure out how to get a stated outcome done. Nobody hand built a sequence for it. It builds its own.

Both are called agents. They are not the same kind of thing, and the difference matters more than the marketing suggests.

What a specialized agent actually is

A specialized agent is closer to a very well automated macro than it is to a colleague. It has a fixed task, a fixed order of operations, and a boundary around what data and systems it can reach. This is not a limitation bolted on as an afterthought. It is the entire design philosophy. You get predictability in exchange for narrowness. When the invoice reconciliation agent runs, you know what steps it took, in what order, against what data, because those steps were specified in advance. If it fails, it fails in a way you can trace to a specific step that did not resolve.

That traceability is not incidental in a finance system. It is the whole point. An auditor does not want to hear that an agent figured out how to close the period. They want a sequence of steps that can be replayed, checked, and defended.

What a generalized agent actually is

A generalized agent like Cowork inverts that trade. Instead of many narrow tools each doing one job, it gets one wide tool and the discretion to decide, at run time, what sequence of actions gets it from the stated goal to a finished result. Ask it to reconcile a vendor’s account for the quarter and it will decide for itself which records to pull, which discrepancies are worth flagging, and in what order to check them. Two runs against the same request, on the same data, are not guaranteed to take the same path to get there.

That is not a bug in the current generation of these tools. It is the feature being sold. A generalized agent does not need someone to have anticipated every scenario in advance and built a process for it. It reasons its way through situations nobody wrote a workflow for. The cost of that flexibility is that the path it takes on any given run is not fully knowable ahead of time, and reproducing it exactly on demand is harder than reproducing a fixed sequence.

The real axis underneath the label

Specialized versus generalized describes the shape of the agent. It does not describe the thing that actually matters to a finance or operations leader deciding whether to trust one of these near a ledger. That deeper axis is deterministic versus probabilistic.

A deterministic process, whether run by a person, a script, or a narrow agent, produces the same output from the same input every time. A three way match either passes or it does not, based on rules that do not change between Tuesday and Thursday. A probabilistic process, which is what a large language model doing open ended reasoning actually is underneath the interface, produces an output that is likely to be correct given the input, not guaranteed to be correct. Run it twice and you may get two answers that are both individually defensible and are not identical.

Specialized agents tend to sit closer to the deterministic end, because their designers constrained the decision space in advance and left little room for the model to improvise. Generalized agents tend to sit closer to the probabilistic end, because improvisation across an open ended tool is the entire value proposition. But the two axes are not the same axis wearing different names, and conflating them is where a lot of the current enterprise anxiety about agents actually comes from. A specialized agent can still make a probabilistic judgment call inside one of its fixed steps, such as classifying a transaction description as likely fraudulent. A generalized agent can still land on a fully deterministic sub task, such as pulling a specific ledger balance, where there is only one correct answer and no room to improvise.

Why D365 F&O is the place this gets tested for real

Dynamics 365 Finance and Operations is a useful proving ground precisely because it already lives with both philosophies side by side. Its native controls, workflow approvals, posting rules, three way match, are deterministic by construction. They were built that way before anyone was talking about agents, because a ledger that produces a different answer on a re-run is not a ledger anyone can close a period against.

Layer Copilot style features and Cowork on top of that and you get a system where the system of record stays deterministic while the layer working on top of it is free to reason probabilistically about what needs attention. That is not a contradiction. It is the correct division of labor. The ledger should never guess. The agent looking for the discrepancy that the ledger’s own rules were not written to catch is allowed to guess, because guessing well is precisely what it is there to do.

The mistake worth watching for is treating a generalized, probabilistic agent as if it were a specialized, deterministic one because it happens to be plugged into the same system. Giving Cowork the same blind trust you would give a fixed three way match rule is a category error. One was built to never deviate. The other was built to deviate on purpose, whenever deviating produces a better answer.

Where this actually lands

Neither shape is the correct answer in general. A specialized agent is the right tool when the process is well understood, the stakes of an unreviewed error are high, and an auditor will eventually ask for the sequence of steps. A generalized agent is the right tool when the problem is not well understood in advance, when the value comes from adapting to a situation nobody scripted for, and when a human is still positioned to review the output before it becomes a transaction that cannot be undone.

The organizations getting this right are not the ones picking a side. They are the ones that have stopped asking whether an agent is good, and started asking where on both axes, specialized to generalized and deterministic to probabilistic, a given task actually belongs. Get that placement wrong in either direction and you either waste a general reasoning tool on a task a five line business rule already solved, or you hand a fixed script a problem it was never built to handle and call the resulting failure a bug instead of what it actually is, a design mismatch.