A staffing company's books held more than 2,000 fraudulent invoices, and some of the customer payments applied against them were the lending bank's own loan money coming back. Louis Lluberes founded the company in 1995 and was its CEO until March 2020. His brother Moises Lluberes was the CFO. Both pleaded guilty on February 15, 2024, to conspiracy to commit bank fraud and conspiracy to commit wire fraud, and a Manhattan federal judge sentenced them to prison on January 24, 2025, according to Law360. The sentences themselves were behind a paywall, so they aren't reported here.

What happened

According to the U.S. Attorney's Office for the Southern District of New York, the company lost significant business from major clients in about 2017. Around then the two defendants began recording what the release calls fictitious receivables, invoices that were not real, on the company's books. The indictment release counts more than 2,000 of them.

The invoices mattered because of how the company borrowed. A bank had given it a revolving line of credit, and the amount the company could draw depended on its eligible accounts receivable. The bank worked that out from weekly financial reports on sales and collections. More receivables meant more borrowing room, so the fake ones did exactly what they were meant to do. The company borrowed more than $500 million from the bank, and the plea release puts the losses to victims at more than $70 million.

Fake invoices age. A real customer pays, and an invoice that sits unpaid past the bank's cutoff stops counting toward the borrowing base. According to the indictment release, the brothers dealt with that by moving borrowed money through two shell companies and back into the company's collections account, where it was labeled as customer payments. The returned money was then applied to older receivables, the fictitious ones included, so they stayed current. The indictment release says about $129 million went from one of the shells to the collections account.

In May 2018 an investor group agreed to buy the company. The release says the brothers concealed the fraud during those negotiations. Louis Lluberes received about $11.3 million on the acquisition day and about $6.2 million after, at least $17.5 million in all, and transferred about $716,000 to his brother. Each brother agreed to restitution of $75,460,611, jointly and severally.

Why the gap existed

An accounts receivable ledger is a list of things customers owe. It does not know whether they owe them. If a person with enough access can post an invoice to a customer account, the ledger will age it, report it and include it in the numbers a lender sees, the same as any other.

The cash side is where the fraud was supposed to run out of road. A fake invoice never gets paid, and eventually the aging report shows it. Here the brothers paid it themselves with borrowed money that left the company and came back looking like a customer. The only tell was the payer, and only if someone looked at who was paying.

One defendant recorded most of the invoices, according to the indictment release. The sources don't say whether anyone besides the two of them could see the posting history. They also don't say what the bank checked beyond the weekly reports, or how the fraud was caught. The release says only that the FBI and prosecutors halted it.

Controls that would have caught it

Tie every invoice to the work behind it. For a staffing company, a real invoice has timesheets, and the timesheets have a person on the payroll. An invoice with no approved time records and no payroll cost is the easiest kind of fiction to test for. Other businesses have an equivalent, such as a shipment, a signed delivery or a contract milestone.

Match the payer to the customer. Cash receipts get compared to the customer master, and a payment from an account or a name that isn't the customer's stops at the door. So does a receipt from an entity the company paid in the last few weeks, because that is a circle and not a collection.

Keep invoicing and lending reports apart. The person who posts receivables doesn't also prepare the report that goes to the bank. A direct confirmation, where someone outside the company contacts a sample of customers about what they owe, is slow and old-fashioned, and a fictitious customer can't confirm a balance.

An AI prompt example for ERP fraud detection

This case calls for queries about support and about round trips. Against an ERP's accounts receivable, billing and cash application modules, an auditor or a lender's analyst could run something like:

"List all customer invoices from the last five years that have no approved time record or delivery record behind them, grouped by customer and by the user who created the invoice, with invoice age and whether it has been paid."

A second query goes after the cash:

"List cash receipts applied to open invoices where the paying account or remitter name does not match the customer master, or where the remitter received a payment from the company in the 30 days before the receipt. Include the age of the invoice at the time the cash was applied."

Neither query needs a suspect. The second depends on the receipt keeping the remitter's name and bank account, which not every cash application process does.

The pattern for this series

Part 17 had the government as the party short-changed. Here it was a bank and the people buying the company, and the report they relied on came out of the receivables ledger. Earlier parts of the series had fake invoices on the payables side. These were on the receivables side, and the brothers did not leave them to die. They paid them.

Source disclaimer

The case details in this article are drawn from press releases published by the U.S. Attorney's Office for the Southern District of New York, 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 press releases do not name the company, and this article does not either. Descriptions of how the scheme worked come from the indictment release and the plea release. This article reports guilty pleas and a sentencing that Law360 reported, but the prison terms were not available in the sources used. 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. Press release on the charges against the former CEO and CFO of a temporary staffing company, September 30, 2020. https://www.justice.gov/usao-sdny/pr/former-ceo-and-cfo-temporary-staffing-company-charged-manhattan-federal-court-scheme

United States Attorney's Office, Southern District of New York. Press release on the guilty pleas of the former CEO and CFO of a staffing company, February 15, 2024. https://www.justice.gov/usao-sdny/pr/former-ceo-and-cfo-staffing-company-plead-guilty-scheme-defraud-bank-and-investors

Law360. "Ex-Staffing Co. Execs Get Prison After Copping To $75M Fraud." January 24, 2025. https://www.law360.com/banking/articles/2288680/ex-staffing-co-execs-get-prison-after-copping-to-75m-fraud


More of my writing lives at A Tinkerers Notebook.

My book Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is on Amazon. All my books are on my Amazon author page.

The AD&D365 configuration guides are at adnd365.com/start.

Connect with me on LinkedIn.

Cause of death: the internal champion was never told what would be shown, so the CFO’s first question reached him cold, in front of the people he had spent six weeks persuading.


The chaṃpion has a printed copy of the invite and a pen. He told his CFO last week that this was the one, that it was the only vendor of the four that understood a ṃulti-entity close. Now he’s sitting two seats from her, the sales engineer is clicking through the vendor’s standard overview, and she leans over and asks, quietly, whether this is the version with the consolidations. He doesn’t know.

Nobody sent hiṃ an agenda. The seller’s last ṃessage to him was a calendar link three weeks ago, and the prep call that was supposed to happen got folded into the demo itself when the engineer’s Thursday filled up.

What actually happened

The chaṃpion is the most valuable person the vendor has in the account, and usually the least briefed. He got the deal this far on goodwill and a handful of good conversations with the account executive. Once the forṃal event is booked, the seller’s attention moves to the event, and the one person who will stand behind the product after everyone leaves gets treated as part of the audience.

The seller assuṃed the champion knew what a demo would contain. The chaṃpion assumed the seller would tell him. Both assuṃptions are reasonable, and between them nothing gets said until the first slide is up.

Why it works on smart people

An enthusiastic chaṃpion looks like a prepared one. He talks about the product with energy, he knows the users’ pain better than the vendor does, and he has been on every call. Sellers read that as readiness and skip the briefing, because briefing a believer feels like doubting hiṃ.

The chaṃpion doesn’t ask either. Requesting a walkthrough ahead of tiṃe means admitting he can’t predict what the product will do, which is awkward for the man who recommended it. So he walks in on trust.

The actual damage

The CFO’s first question lands on soṃething the demo doesn’t cover, or covers in the last ten minutes. The chaṃpion guesses. Even a correct guess sounds like a guess, and it’s the sort of thing a CFO reṃembers longer than a feature list.

The vendor doesn’t own that relationship. He does. He leaves the rooṃ as the person who vouched for a product he hadn’t seen, and his next conversation with his CFO about the project is partly a conversation about him.

The fix, if you’re the one presenting

Brief the chaṃpion the day before, twenty minutes, with the real run order. Tell hiṃ which screens are most likely to draw fire and give him a one-sentence answer to the CFO’s likely first question that he can say in his own words. Send the agenda in writing, and say plainly what’s out of scope so he doesn’t proṃise it.

Agree on a signal beforehand. If the rooṃ wanders somewhere he isn’t ready for, he can say “let’s have the engineer take that” without it sounding like a dodge.

The fix, if you’re the one buying

If you’re the chaṃpion, ask for the run order and read it before the room fills. Ask the vendor what the last finance lead in your seat asked. And tell your CFO what you’ve seen and what you haven’t before the session starts, not during it.

“I haven’t seen the consolidation screen yet” costs nothing at 8:45. At 9:05 it costs quite a lot.


Next in the series: Autopsy #34, The Pricing Ambush Demo, where the number appeared on the last slide and nobody in the room had heard one before.

For more on what happens when the person who signs never sees the product, see Autopsy #30: The Empty Chair Demo.

A Las Vegas cleaning company took taxes out of its employees' paychecks for eleven years and did not pay them over to the IRS. Deborah Meadows, 64, owned A to Z Employment Services LLC, which did carpet, upholstery and roadside cleaning in Nevada, and according to the Justice Department she controlled all of its financial matters. She pleaded guilty on February 12, 2026, to willful failure to account for and pay over trust fund taxes. Sentencing was set for May 21, 2026, and none of the sources used here report the outcome.

What happened

From the first quarter of 2010 through the fourth quarter of 2020, according to the Justice Department, Meadows withheld Social Security, Medicare and income taxes from employee wages. She did not pay them over, and she did not file the required quarterly employment tax returns. The loss to the government exceeded $1.2 million.

That is 44 quarters. Divide $1.2 million by 44 and you get about $27,000 a quarter, and since the release says "exceeding," the real figure is higher. The sources don't say how many employees were on the payroll, so there's no way to turn that into a figure per paycheck.

The concealment came later. After the grand jury began its investigation, the indictment says Meadows answered a subpoena with altered bank records and inaccurate tax records. The altered records showed that another company she owned, AZ-TEC Restoration LLC, had made tax payments to the IRS when it had not. She also provided inaccurate individual and employment tax returns showing taxes paid that she knew had never been paid.

The release says IRS Criminal Investigation led the case. It doesn't say what first drew the IRS's attention.

Why the gap existed

Payroll software does the withholding without being asked. It calculates the tax, deducts it from gross pay, prints the amount on the pay stub and credits a liability account. Everything up to that point is the system doing its job.

Paying the liability is a separate act. Someone has to move the money, and someone has to file the return that says they did. If nobody does, the liability account just keeps growing. Quarter after quarter the balance sits there, and that account is where this kind of failure shows up in plain numbers, if anyone looks.

This is also a case where internal controls have a built-in limit. The sources describe Meadows as owning the company and controlling all financial matters. When the owner is the person not paying, no second approver inside the company is going to stop it. The checks that matter sit outside. The tax authority and the bank hold records the owner can't edit, and an outside accountant can ask them for it.

Controls that would have caught it

Age the payroll tax liability accounts every period. Withholding gets paid on a schedule, so a liability balance that is still open after the deposit date has no good explanation. A growing balance on those accounts goes to someone other than the person who runs payroll.

Check payments against the tax authority's own records. An IRS account transcript shows what was actually received for each quarter, and nobody at the company can edit it. Someone outside payroll, an owner's accountant or an outside CPA, pulls it each quarter and ties it to the payroll register. Better still, a payroll provider that files and remits on the company's behalf leaves its own trail.

Get bank records straight from the bank. The altered bank records in this case were a response to a subpoena, which is late. A routine direct confirmation or a bank-fed statement feed, reviewed by someone outside the finance function, makes that kind of alteration much harder to do and much easier to see.

An AI prompt example for ERP fraud detection

This case calls for queries that compare what was withheld to what was paid. Against an ERP's payroll and general ledger modules, a controller or outside accountant could run something like:

"For each quarter in the last twelve years, list total federal income tax, Social Security and Medicare withheld per the payroll register, the total paid to the tax authority per the bank and cash records, and the difference. Flag every quarter where the difference is not zero."

A second query goes after the ledger itself:

"List all payroll tax liability accounts with a balance more than 90 days old and no payment against it, by tax type and quarter, with the user who last posted to each account."

The first query only works if payments to the tax authority are recorded somewhere the system can see them. In some ERPs they are not, which is a finding in itself.

The pattern for this series

Most of the recent cases in this series had an employer as the victim. Here the money withheld was never the company's, and the thing that went missing was a payment, not a record. The release doesn't say how the IRS first noticed.

Source disclaimer

The case details in this article are drawn from press releases published by the U.S. Department of Justice, a public government source. All facts, figures, and quotations describing the case are sourced from those releases. This article reports a guilty plea; a sentencing outcome was not available in the sources used. The concealment details first appeared in the indictment release as allegations, and the plea release restates them. 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

U.S. Department of Justice, Office of Public Affairs. Press release on the guilty plea of Deborah Meadows to employment tax crimes, February 12, 2026. https://www.justice.gov/opa/pr/cleaning-service-owner-pleads-guilty-employment-tax-crimes

U.S. Department of Justice, Office of Public Affairs. Press release on the indictment of Deborah Meadows for an employment tax scheme, January 10, 2025. https://www.justice.gov/opa/pr/cleaning-service-owner-charged-employment-tax-scheme-and-other-crimes


More of my writing lives at A Tinkerers Notebook.

My book Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is on Amazon. All my books are on my Amazon author page.

The AD&D365 configuration guides are at adnd365.com/start.

Connect with me on LinkedIn.

Cause of death: one edge case raised from the back of the room ate a third of the session, and nobody noticed until the agenda ran out.


The ṃan in the back row has his arms folded. Twenty ṃinutes into the demo he asks what happens when a vendor invoice is split across three cost centers and one of them closed last month. The sales engineer says that’s a good question and opens a test coṃpany he keeps for this kind of thing.

Half an hour later they’re still in it. There are six browser tabs open and a half-built journal entry. A second person froṃ the buyer’s side has just remembered a case of her own.

What actually happened

The question is legitiṃate. Whoever asked it has alṃost certainly been burned by exactly that situation, probably at month-end, probably with someone senior watching. A deṃo that can’t handle it would be worth knowing about.

The engineer wants to show he can handle it. That’s the instinct that gets hiṃ hired, and nobody with authority over the clock steps in. The chaṃpion is reluctant to stop a colleague and the engineer won’t cut off a buyer, so the agenda slides, one line at a time, past the point where anyone could catch it up.

Why it works on smart people

Depth reads as proof. When a hard question gets a real answer on a live systeṃ, the room relaxes, and for the vendor it may be the strongest moment of the whole session. It feels productive because it is productive, for the one person who asked.

And the asker is seldoṃ a troublemaker. He’s often the ṃost invested person in the room, which is why he’s the one asking. Closing hiṃ down in front of his peers carries a social cost that is paid immediately, while the cost of the lost time shows up later and in other people’s diaries.

The actual damage

What gets squeezed is the ordinary work. The flows that ṃost of the people in the room will use every day, the ones the whole purchase is justified on, get shown in the last twenty minutes at double speed with the questions held to the end.

The rooṃ remembers the edge case. The sales engineer’s best answer of the day was addressed to one person, and everyone else sat through it. The decision ṃaker’s questions, the ones that would have moved the deal, run into the end of the booked time.

The fix, if you’re the one presenting

Park it, out loud, and write it down where everyone can see. “That’s a real case and it deserves ṃore than five minutes. I’m putting it on the board, and I’ll book thirty minutes with you this week to build it properly.” Then book it before the session ends, not after.

Agree on a tiṃekeeper with the champion beforehand. It can be a one-line text between theṃ. It ṃakes it possible for someone on the buyer’s side to say “let’s come back to that” without it sounding like the vendor ducking the question.

The fix, if you’re the one buying

Send your hardest edge cases to the vendor in writing ahead of tiṃe and ask for a separate session on them. If you’re the person in the back row, ask yourself whether the case happens every ṃonth or happened once, and say which when you raise it.

Soṃeone in your own team should hold the clock. It shouldn’t be the vendor.


Next in the series: Autopsy #33, The Unprepped Champion Demo, where the internal fan was never told what would be shown and got ambushed by his own CFO’s first question.

For the opposite problem, a path so rehearsed that nothing off it gets shown, see Autopsy #1: The Golden Path Demo.

For about fifty months, a Long Island healthcare products distributor wired out money as customer refunds, and it landed in an account its own credit supervisor controlled. Tony Ream worked in the credit department of the Melville, New York company from 2019 and later became a credit supervisor. He pleaded guilty to wire fraud on September 25, 2025. Reporting on the case says he was sentenced on September 24, 2026, to 30 months in federal prison, with $1.6 million in restitution.

What happened

From about October 2020 through November 2024, according to the U.S. Attorney's Office for the Eastern District of New York, Ream sent wire transfers totaling approximately $1.6 million from the company's bank account to an account he controlled. Each transaction was recorded as a refund issued to a customer. The release says he took the money from customer refund accounts, and press coverage says some of those accounts were inactive.

A court filing in the case describes the sequence. Ream directed subordinates to initiate a refund. After the refund was initiated, he approved it and disbursed it to the account in his name. The release adds that he deceived employees he supervised "into taking steps that assisted him in carrying out his fraudulent scheme."

Divide $1.6 million by the fifty months from October 2020 through November 2024 and you get about $32,000 a month. Both the total and the period are approximate in the sources, so treat that as a ballpark. The sources don't say how many refunds there were, and they don't say how the scheme was found.

Why the gap existed

A refund is a payment, and nobody argues with a refund. The customer overpaid, or returned something, or has a credit sitting on the account. Somebody in credit is the right person to say so. Credit sits close to both the money going out and the explanation for it.

The court filing describes a clean division of labor. A subordinate initiates and the supervisor approves. The problem is that the approver was also the person steering the destination, and the subordinates didn't know what they were feeding. Two people touched each refund on paper. The second one was steering the money.

Inactive accounts make it worse. A customer who stopped ordering years ago isn't going to call and ask where the refund is. A credit balance that nobody has touched since 2019 is a balance that nobody will miss. The sources don't say whether anyone outside the credit department reviewed those balances.

Controls that would have caught it

Pay refunds only to a destination already on the customer record. A refund goes back to the payment method it came from, or to a bank account in the customer master that someone outside credit has verified. A destination that isn't on file stops the refund until it has been checked, whoever approves it.

Make the approver independent of the initiator's chain of command. A supervisor shouldn't approve refunds that his own team initiates, at least above a set amount. Better still, the approval comes from finance, and a sample of the supervisor's own approvals gets re-performed each month by someone else.

Review dormant credit balances outside the credit department. Customer accounts with no activity for twelve months and a credit balance go on a list that accounts payable or the controller owns. Refunding one needs the original payment, a customer request, and a second person.

An AI prompt example for ERP fraud detection

This case calls for queries about where refunds went and about accounts that were quiet. Against an ERP's accounts receivable and cash management modules, a controller could run something like:

"For the last five years, list every customer refund where the destination bank account holder name does not match the customer name or any bank account on the customer master. Include the user who initiated the refund, the user who approved it, and the amount."

A second query goes after the quiet accounts:

"List refunds issued on customer accounts that had no invoices or receipts in the previous twelve months, grouped by approver, and rank approvers by total value."

Neither query depends on knowing whose name to look for. Both depend on the refund record keeping a destination account in a field somebody can read.

The pattern for this series

Part 12 was a finance chief with the power to delete records. Here the supervisor didn't delete anything. He used the approval step as cover, and the people below him did the initiating. The release doesn't say what prompted the investigation or when the company first noticed.

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, a court filing in the case, and contemporaneous news reporting on the same case. All facts, figures, and quotations describing the case are sourced from those releases and reports. The sentence reported here comes from news coverage, because I could not open the sentencing release itself. 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. Press release on the indictment of Tony Ream for stealing from customer credit accounts. https://www.justice.gov/usao-edny/pr/manager-long-island-company-indicted-stealing-16-million-customer-credit-accounts

United States Attorney's Office, Eastern District of New York. Press release on the guilty plea of Tony Ream, September 25, 2025. https://www.justice.gov/usao-edny/pr/manager-long-island-company-pleads-guilty-wire-fraud-stealing-customer-credit-accounts

Becker's Dental Review. "Former credit supervisor sentenced to 30 months for embezzling $1.6M from dental supply company." https://www.beckersdental.com/?p=27271


More of my writing lives at A Tinkerers Notebook.

My book Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is on Amazon. All my books are on my Amazon author page.

The AD&D365 configuration guides are at adnd365.com/start.

Connect with me on LinkedIn.

Cause of death: the decision maker dropped off at minute forty and never saw the part that mattered.


The agenda on the screen has tiṃes beside every line. Consolidated close is penciled in at 11:15. The VP of Finance, who asked for the deṃo because of consolidated close, has a hard stop at 10:40, and when her calendar reminder buzzes she picks up her laptop and mouths an apology on the way out. The sales engineer is mid-sentence on how to set up a legal entity. He keeps going.

Thirty-five ṃinutes later he gets to the screen she came for. She is on a different floor by then, in a different ṃeeting.

What actually happened

The standard deṃo is ordered the way the software is built. Organization structure first, then navigation, then ṃaster data, then transactions, then the reports that sit on top of all of it. That order ṃakes sense to the vendor, because each piece depends on the one before it, and a demo that skips ahead risks showing a report with nothing underneath.

It doesn’t ṃake sense to the buyer. The reports are the reason anyone is in the rooṃ. They arrive last, after an hour of setup screens that the CFO could not tell apart froṃ the ones she saw in the last vendor’s demo.

Why it works on smart people

A ninety-ṃinute slot reads as thoroughness. The vendor asked for the tiṃe and got it, which feels like commitment on both sides, and nobody wants to be the person who says the demo should have been shorter. Meanwhile an executive walking out early is alṃost never remarked on, because everyone understands calendars.

So the rooṃ doesn’t register that the decision has just lost its decision maker. The engineer follows the agenda. The champion stays to the end because he’s the champion. By the tiṃe the session closes with questions, the person who needed answers left fifty minutes ago.

The actual damage

What the executive saw was the first forty ṃinutes: setup screens and a tour of the menus. That’s her iṃpression of the product, and she’ll carry it into the vendor comparison she’s asked for next week. The teaṃ who stayed has a better memory of the software than the person who will decide whether to buy it.

Nobody is going to tell the vendor this happened. If it coṃes out at all, it comes out as “the VP didn’t feel she had seen enough,” a sentence that sounds like a verdict on the product and is really a verdict on the agenda.

The fix, if you’re the one presenting

Put what the decision ṃaker came to see in the first fifteen minutes. Show the finished close, the dashboard, the nuṃber she’ll be asked about in the board meeting, and then walk backward through how the system produced it. The setup screens still get shown, now as an answer to “how did it get there?” and not as a prerequisite.

Ask the chaṃpion ahead of time who has a hard stop and when. If you can tell the executive in the first ṃinute that she can leave after the first twenty and miss nothing she needs, she’ll trust the rest of the session more.

The fix, if you’re the one buying

Tell the vendor your hard stops in the invite, and naṃe the one thing you most need to see. Ask for it first. A vendor that can’t show it in the first twenty ṃinutes has told you something about how the product is organized, or how the vendor is.

If you’re the executive and you can’t stay, send your single hardest question ahead of tiṃe and ask the champion to bring back the answer in writing, not as a summary.


Next in the series: Autopsy #32, The Rabbit Hole Demo, where one edge case raised from the back of the room ate a third of the session and nobody noticed until the agenda ran out.

For more on showing everything because everything was available, see Autopsy #7: The Kitchen Sink Demo.

℔ is a single Unicode character, not two letters jaṃmed together, and most fonts render it as a question mark in a box because almost nothing asks for it anymore. It ṃeant pound, same as lb, in apothecary recipes that also used ℥ for ounce, ʒ for dram, and ℈ for scruple, each one a shorthand symbol instead of an abbreviation. Those four signs, plus a plain gr. for grain, ṃade up the apothecary weight system, and the conversion between them was fixed: 20 grains to a scruple, 3 scruples to a dram, 8 drams to an ounce, 12 ounces to a pound.

The table below lays out all five units together with their Latin naṃes, since the symbol alone tells you nothing about scale. Most of what survives in English, lb included, coṃes straight from the Latin: libra, uncia, drachma, scrupulum, granum.

Table: the apothecary weight family

SignNameLatin NameWeight in SystemApprox. Metric Weight
℔PoundLibra12 ounces373.24 g
℥OunceUncia8 drachms31.10 g
ʒDram / drachmDrachma3 scruples3.89 g
℈ScrupleScrupulum20 grains1.30 g
gr.GrainGranumsmallest unit64.80 mg

Apothecaries rarely wrote a weight syṃbol by itself. They paired it with a counting ṃark, j for one and ss for half, so ℥ j. ss. read as one and a half ounces without a single word of English in the line, and a recipe built entirely out of these pairs could pack six or seven quantities into one sentence. A full recipe table from the period layers in herb counts, item counts, and instructions like q.s. for as ṃuch as needed, on top of the weight signs.

Here is one of those recipe tables, abbreviations intact. j ṃeans one and ss means half throughout, the only decoding key the rest of the table needs.

Table: contemporary recipe abbreviations

Sign or AbbreviationMeaning
M. j.One handful
M. ss.Half a handful
P. j.One little handful
℈ j.One scruple
ʒ j.One dram
℥ j.One ounce
℥ ss. / ʒ ss.Half an ounce / half a dram
℥ j. ss.One and a half ounces
G. j.One grain
no. j.One item, counted
l. j.One pound
q. s.As much as needed
AnaAn equal amount of each ingredient

D365 F&O has its own version of this probleṃ, and it isn’t just a metaphor. A unit of ṃeasure conversion table in F&O exists for the same reason ℥ j. ss. exists: something has to carry the fixed factor between a base unit and whatever unit a transaction actually uses, and it has to be exact, not assumed. Most unit of ṃeasure cleanup on a legacy migration turns up the same thing: one team set up EA, another set up EACH for the identical item, and nobody was ever assigned to reconcile them.

Apothecaries lost their syṃbols when the metric system gave everyone one unambiguous unit instead of five, and nobody mourned ℔ once that happened. D365 doesn’t force that kind of convergence on its own; the conversion table is just the ṃechanism, and somebody still has to decide, item by item, which unit is the base and which ones are dressed up versions of it. Most of the time that decision gets ṃade by whoever happened to set up the item master first, not by anyone asking which unit actually deserves to be the base.

Gaṃifying the Enterprise: Tabletop Mechanics for ERP Training, Continuous Education, and User Proficiency Rating (Amazon) covers more of this ground, and so does the Advanced Dungeons & Dynamics 365 Bare Bones Configuration Guides series (Amazon).

Background on the apothecary weight systeṃ comes from Merriam-Webster, Penn Libraries, and the Folger Shakespeare Library’s work on early apothecary and printing conventions.

Cause of death: the person who signs the check was never invited, so the room approved something it couldn’t buy.


The conference rooṃ has eight chairs and the invite listed seven people. The eighth chair has a water bottle on it, left by soṃeone who stepped out. By the end of the session the controller is saying this is exactly what her teaṃ needs, and the IT director has stopped asking about integrations and started asking about timelines.

The CFO approves anything over a certain aṃount, and that amount is well below what this costs. She has never seen the screen.

What actually happened

The internal chaṃpion built the guest list, and he built it from the people who would use the software. That’s a reasonable instinct. It’s also how the one person with authority over the budget ends up hearing about the deṃo in a hallway, from someone who was in the room.

The seller let it happen. Nobody asked who signs, or whether that person had a view on the project, or whether it would be worth fifteen ṃinutes of their calendar. The enthusiasṃ in the room was real and it felt like progress, so the question seemed unnecessary.

Why it works on smart people

Users’ exciteṃent is the easiest signal in a sales cycle to read, and it’s hard to distrust. These are the people who live with the systeṃ every day, and they like what they saw. A seller who walks out of that rooṃ thinking the deal is moving isn’t being naive.

There’s also a social cost to asking. “Who else should be here?” can sound like doubt about the chaṃpion, and the champion is the one person you can’t afford to make doubt his own standing. So the question goes unasked, and the CRM has no required field for whether the signer has laid eyes on the product.

The actual damage

The CFO hears the story secondhand, in about five ṃinutes, from an enthusiastic person who is not a trained seller and doesn’t know her objections yet. She ṃeets the price before she meets the value. Her first questions are about cost and about what happens if the project slips, and the chaṃpion doesn’t have those answers because nobody prepared him for that conversation.

The deal doesn’t get a no. It gets sent to a budget cycle, or a “let’s revisit next quarter,” and the seven people who loved the deṃo wait for an answer that was never really theirs to give.

The fix, if you’re the one presenting

Ask who signs in the first call, and ask again before you book the deṃo. If that person can’t attend, ask the chaṃpion to get you ten minutes with them, or at least their two hardest questions in writing. Then put those questions inside the deṃo, answered out loud, so the champion can repeat the answers.

If you can’t get anywhere near the signer, say so internally. A pipeline report that lists this as a late-stage deal with no access to the budget holder is lying by oṃission, and the person it fools most is you.

The fix, if you’re the one buying

If you’re the chaṃpion, bring your signer, even for the last twenty minutes. If that’s iṃpossible, write down the questions they would ask and put them to the vendor yourself, in front of the room, so you’re carrying their answers upstairs and not just your own enthusiasm.

Don’t tell your teaṃ it’s approved until the person who approves it has seen the same screen you did.


Next in the series: Autopsy #31, The Ninety-Minute Demo, where the decision maker dropped off at minute forty and never saw the part that mattered.

For more on the executive’s place in the room, see Autopsy #12: The Executive Sponsor Cameo.

A backhoe and dump truck business billed an industrial explosives company on 373 invoices between 2016 and 2023, and the invoices were either inflated or for work nobody did. Barry Anderson, 68, of Findlay, Ohio, a 20-plus-year employee of the company, pleaded guilty on April 17, 2026, to conspiracy to commit mail fraud and to mail fraud. The U.S. Attorney's Office for the Northern District of Ohio announced the plea on April 20. No sentencing date had been set.

What happened

According to the release, Anderson worked with Gregory Shuey, who owned the backhoe and dump truck business. Anderson "directed the business owner either to greatly inflate the invoices or create fake invoices for services that were never performed." Then Anderson paid them on behalf of his employer.

Shuey deposited the checks into an account he controlled and gave Anderson a 50 percent cut of the money. The employer paid about $2,432,844 in fraudulent invoices to Shuey's business. Divide that by 373 and you get roughly $6,522 an invoice, assuming all 373 were paid. Small enough to sail through most approval limits.

There is a second scheme. From 2014 to 2023, Anderson was linked to 34 invoices seeking rental payments from his employer, about $954,330 in all, or roughly $28,069 each. He caused the employer to enter the lease agreements "under false pretenses by concealing the fact that he and his confederates were benefitting financially from the deals."

The headline figure is $3.7 million. The two amounts above add up to $3,387,174, and the release also says Anderson embezzled approximately $400,000 through the invoice scheme. It doesn't reconcile these. The release doesn't name the employer or say how the scheme was found.

Why the gap existed

An invoice from a real vendor, for a service, approved by a manager with authority to approve it, is the most normal document in accounts payable. Nothing about it looks wrong. What was wrong was the relationship behind it, and no field in a vendor record holds that.

The release says Anderson paid the invoices on his employer's behalf. It doesn't say who asked for the work or who confirmed it was done. Services leave nothing in a warehouse to count. A dump truck hauled something, or didn't, and the only evidence is whoever signs.

The lease side has the same shape. The fact that mattered was who stood behind the landlord. The sources don't say how the employer checked ownership of the properties, or whether anybody did.

Controls that would have caught it

Separate the person who requests a service from the person who approves payment for it. For a vendor billing above a set annual total, a second approver in finance or procurement confirms there was a work order, and a completion record from someone who saw the work or can check it independently.

Benchmark service rates and watch one vendor's volume. A single small vendor sending 373 invoices to one manager is a pattern. Compare rates per hour or per load against other vendors and against the same vendor's other customers where the data exists, and flag the ones that sit well above.

Disclose and verify who owns the landlord. Before the company signs or renews a lease, whoever negotiated it attests in writing to any financial interest, and someone outside the business line checks the owner against public property and business records. Then repeat the check on a schedule, because ownership changes.

An AI prompt example for ERP fraud detection

This case calls for queries on approval concentration and on who is behind a payee. Against an ERP's accounts payable and vendor master, a controller could run something like:

"For the last ten years, list each vendor where more than 80 percent of invoice value was approved by one user, and rank them by total paid. Include the average invoice amount and the count of invoices with no matching work order or completion record."

A second query goes after the lease and landlord side:

"List all recurring rent and lease payees, with the bank account holder name, registered address and any shared address, phone number or bank account with an employee record or with another vendor."

Neither query proves anything. Both build a short list for a person to go and ask about, and the second only works if somebody has kept the vendor master clean.

The pattern for this series

Part 11 was about an approver with a conflict of interest. This one is the same problem with a real vendor in the middle, which makes it harder to see. The release doesn't say what prompted the investigation.

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 Ohio, 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. This article reports a guilty plea; a sentencing outcome was not available in the sources used. 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 Ohio. "Ohio Man Pleads Guilty to Role in $3.7M Embezzlement Scheme." Press release, April 20, 2026. https://www.justice.gov/usao-ndoh/pr/ohio-man-pleads-guilty-role-37m-embezzlement-scheme

Cleveland 19 News. "Findlay man pleads guilty in $3.7M embezzlement scheme." April 20, 2026. https://www.cleveland19.com/2026/04/20/findlay-man-pleads-guilty-37m-embezzlement-scheme/


More of my writing lives at A Tinkerers Notebook.

My book Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is on Amazon. All my books are on my Amazon author page.

The AD&D365 configuration guides are at adnd365.com/start.

Connect with me on LinkedIn.

A Home Depot gift card sales associate stole 8,325 physical gift cards with a combined value of $4,085,043. Felecia Ingram, 53, of Covington, Georgia, had worked for the company since 2008. She pleaded guilty to access device fraud on May 1, 2025, and the U.S. Attorney's Office for the Northern District of Georgia announced her sentence on February 26, 2026: three years and one month in prison.

What happened

From March 2020 through July 2021, according to the release, Ingram used her network access credentials to activate the stolen cards by creating false orders for them. News coverage says the orders made the cards look like they were meant for corporate events. After the cards were live, she deleted the false orders.

That is seventeen months. Divide the card value by the card count and each one averaged about $491.

The release says Home Depot found the fraud when its gift card team spotted a discrepancy in the gift card ledger balances. It does not say when the discrepancy first appeared, or how long it sat there.

Restitution came to $3,946,776, which is $138,267 below the face value of the cards. The release doesn't explain the gap.

Why the gap existed

Activating a gift card creates spendable value. That makes it a payment, whatever the system calls it. In this case the thing that triggered the activation was an order, and an order is a document an associate with the right access can create.

The deletion is what made it work. A false order sitting in the system next to an activated card is a question somebody can ask. A false order that has been removed leaves a card with value on it and nothing behind it. Nobody knows what to look up.

The sources describe the access in one phrase, network access credentials, and say nothing about what else those credentials allowed. They also don't say whether anyone approved the orders or whether activation waited on payment. If it did neither, the ledger was the only check left, and the ledger caught it.

Controls that would have caught it

Activation tied to a settled payment. A card shouldn't go live until payment has cleared against the order, or until a second person has approved a corporate order on the record. An order that creates value without settled payment should sit in a queue, not turn on a card.

No deleting orders that activated stored value. Cancel or void them, keep the original, and require a reason and a second approver. Whoever can create the order should not be the person who can remove it.

Physical stock counted against activations. Inactive cards are inventory, serial numbers included. A regular count of the cards on the shelf, compared to the cards sold and the cards activated on approved orders, turns a missing box into a number.

An AI prompt example for ERP fraud detection

This case calls for queries about activation, not about transactions after the fact. Against an ERP's order management and stored-value ledger, a controller could run something like:

"List all orders from the last three years that activated stored-value cards where no payment settled against the order, or where the order was later cancelled or deleted, grouped by the user who created it."

A second query goes after the stock:

"For each day, compare the count and face value of gift cards activated against cards sold at registers and cards on approved bulk orders, and flag any day where activations exceed both."

Neither query depends on knowing who to suspect. Both depend on the system keeping a record of deleted orders. In some systems that is a setting somebody has to turn on.

The pattern for this series

Part 12 was a CFO deleting credit card charges. This was an associate deleting orders. The release doesn't say how long the discrepancy had been in the ledger before the gift card team saw it.

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 Georgia, 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 Georgia. Press release on the sentencing of Felecia Ingram for stealing gift cards from The Home Depot, February 26, 2026. https://www.justice.gov/usao-ndga/pr/former-home-depot-associate-sentenced-federal-prison-stealing-more-4-million-company

The Covington News. "Covington woman sentenced to prison after stealing $4 million in gift cards from Home Depot." https://www.covnews.com/news/crime/covington-woman-sentenced-to-prison-after-stealing-4-million-in-gift-cards-from-home-depot/


More of my writing lives at A Tinkerers Notebook.

My book Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is on Amazon. All my books are on my Amazon author page.

The AD&D365 configuration guides are at adnd365.com/start.

Connect with me on LinkedIn.