Archive

Monthly Archives: September 2026

An Advanced Dungeons & Dynamics 365 session. Episode 13 of 14.

Previously on: Episode 12, The Customization Nobody Remembers, Vex found a two year old tax override still running on top of a platform fix that made it unnecessary eighteen months ago, which meant international tax had likely been calculated twice for a very long time.

Two weeks to go live, and the party finally has to decide what to do with a discovery that’s bigger than a bug fix. This episode is about the moment a technical finding becomes an ethical one.


The Session

Vex: The override was patching a tax bug. The bug was fixed in a platform update eighteen months ago. Nobody removed the patch.

Sable: So for eighteen months, international tax has been calculated twice. Once correctly by the platform, once again by the leftover override.

Thorne: Every international order in that window needs review.

Ai. Cassiopeia: I can generate the affected transaction list. It is not small.

Marge: Feld needs to know today. Not after go live.

The party requests an unscheduled meeting. Feld reads the summary standing up, without sitting down first, which everyone in the room understands as a bad sign before he says a word.

Feld: (reading the list) This goes to audit and legal before it goes anywhere else.

Thorne: That’s the right call. It’s not a great one. But it’s the right one.

Feld: (setting the list down carefully) Two go live attempts failed because people were afraid to bring me news like this. You just did it anyway.

Marge: That’s the job.

Feld: I know it is. I’m still noticing that it happened.

Vex: There’s a smaller silver lining, if it helps. The overcorrection was consistent and directional. It should make the reconciliation methodical rather than exploratory. We know exactly what we’re looking for.

Ai. Cassiopeia: I concur. This is not a needle in a haystack. It is a known pattern applied against a known window.

Feld: (a short, tired exhale that’s almost a laugh) After everything else this project has thrown at me, “at least it’s a known pattern” is genuinely reassuring. That says something about the last four months.

Sable: It says the bar moved. Not that this is small.

Feld: Understood. Bring in whoever you need. What does the timeline look like with audit and legal both in the loop?

Feld authorizes disclosure, pulls in audit, and, for the first time in the engagement, asks the party what go live actually needs from him personally.


The moment disclosure stops being optional

Every episode up to this one has been about finding a problem and deciding how to fix it. This one is different, because the discovery crosses a line where “fix it quietly and move on” was never actually on the table. A tax miscalculation across a known window of international orders isn’t a configuration issue the team gets to resolve on its own judgment. It has legal and regulatory weight that belongs to people outside the war room, and pretending otherwise, even with good intentions, would have been a much bigger risk than the original bug.

What’s worth noticing is how unremarkable the decision to disclose actually was, once it got made. Marge’s line, “Feld needs to know today, not after go live,” isn’t dramatic. It’s the obvious, boring, correct call, and it’s only notable at all because of everything the party has learned about this project over twelve episodes: two prior go live attempts where the vague language of “data quality issues” let real problems go unnamed. Feld himself sitting through disclosures he could have made and didn’t. The default on this project, before this episode, was to let uncomfortable news dissolve into something softer before it reached the person who needed to hear it clearly.

Feld’s response is the real payoff of everything episode seven and eight built. He doesn’t get defensive. He doesn’t ask if it can wait. He reads the finding standing up, makes the harder call immediately, and then does something a lot of sponsors never manage: he notices out loud that the team told him the truth without being forced to, and says so, rather than treating honesty as the baseline he was owed all along.


What happens next

Audit and legal are engaged, the timeline is adjusted to account for it, and the party heads into the final stretch with every major fire from the last twelve episodes either resolved or actively being managed in the open. Cutover weekend arrives, and every fix built over the course of this campaign gets tested at once, live, in front of the whole company.

Next episode: Episode 14, Go Live Weekend, the campaign finale (coming soon)


If your team has ever found something that needed to go to legal or audit before it went anywhere else, you know exactly how heavy that meeting feels. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want a framework built around surfacing findings like this one clearly and early, instead of letting them soften into something vaguer, start here: adnd365.com/start

In 2009, a former branch manager at Randstad was sentenced to five years and one month in federal prison for wire fraud and aggravated identity theft. The scheme ran for three years before anyone caught it. The method behind it was almost boring, which is exactly why it worked.

What happened

Cynthia Whitehead used the real names of former Randstad employees, people who had already left the company, to generate wage payments through the payroll system. She then kept those “wages” for herself. From 2004 to 2007 she embezzled more than a quarter of a million dollars this way. She pleaded guilty on July 8, 2009, and was ordered to pay $286,388.37 in restitution on top of the prison sentence.

Nobody defeated a clever fraud control here. The scheme worked because a former employee’s identity remained valid and payable inside the system long after that person had stopped working there.

Why the gap existed

The failure point sits exactly at the boundary between two systems that were supposed to agree with each other: HR, which knew someone had left, and payroll, which kept generating payments as if they hadn’t. That boundary is where this kind of fraud always hides. It isn’t defeating a rule. It’s exploiting the fact that two systems of record were allowed to disagree for as long as nobody checked.

A termination event should be the kind of thing that instantly and automatically closes off every downstream ability to pay that person again. In practice, in a lot of ERP implementations, it’s a status field that gets updated in one module and trusted to eventually matter everywhere else. Three years of undetected fraud is what “eventually” costs.

Controls that would have caught it

The control here isn’t exotic. A payroll run should not be able to issue a payment to any employee ID with an active termination date, full stop, checked at the moment of disbursement rather than assumed from a status flag set once and never re-verified. In practice, this means the integration between the HR module and the payroll module needs to function as a hard gate on every pay run, not a background sync that payroll happens to respect most of the time.

The harder part isn’t designing that rule. It’s noticing that it needs to be designed at all, because on paper the termination process already “worked.” The employee’s status did get updated. Nobody had built the check that made that status update actually block a payment.

An AI prompt example for ERP fraud detection

This is a case where an AI-assisted review layer earns its keep, not by replacing the underlying control but by making it cheap enough to run constantly instead of only during an annual audit. Against the ERP’s HR and payroll data, a controller could run something like:

“List every payroll disbursement in the last three fiscal years paid to an employee ID with a termination date recorded prior to the pay period start date.”

A second, complementary query catches slower variants of the same pattern:

“Flag any employee ID that received a payment more than 30 days after their most recent termination or leave-of-absence date recorded in HR.”

Neither prompt requires new system functionality. Both require someone to think to ask the question on a recurring basis rather than only after a tip or an audit forces the issue. That is the actual lesson of this case. The rule that would have stopped it wasn’t complicated. It just wasn’t being asked.

The pattern for this series

This is the first case in a series looking at real, documented ERP fraud schemes: what happened, what shared assumption in the underlying system let it run, what a properly governed control looks like, and a concrete AI prompt that turns a periodic audit question into something that can run continuously. The goal is never to suggest AI replaces the governance. It’s to show what becomes possible once the 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 Northern District of Georgia, a public government source. All facts, figures, and quotations describing the case are sourced from that release. 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. “Former Randstad Branch Manager Sentenced to Federal Prison for Embezzlement.” Press release, September 16, 2009. https://www.justice.gov/archive/usao/gan/press/2009/09-16-09c.pdf

Cause of death: the competitor being demoed against would not have recognized itself.


Midway through the pitch, the slide changes to a comparison. Two columns, sometimes three. Your product on one side, the competitor on the other, a row of checkmarks and X marks running down the middle. The competitor’s column is thinner than it should be. A feature they shipped eighteen months ago is marked absent. A limitation they fixed two releases back is presented as current. The pricing comparison uses the competitor’s list price against your negotiated discount. By the end of the slide, the choice looks obvious, because one column was built by a team with every incentive to make it look that way, and the other was built by nobody in the room.

Nobody in the room raises a hand and asks when this comparison was last verified. That’s the autopsy. A competitive comparison built entirely by one side, unchecked by the other, isn’t a comparison. It’s a résumé written by an opponent’s rival, and it gets read with the same scrutiny either way, which is to say, functionally none.

What actually happened

Every competitor’s product roadmap moves faster than any comparison sheet does. A gap that was accurate when a sales engineer built the deck eighteen months ago has, more often than the room assumes, already been closed, sometimes through a native feature, sometimes through a partner integration or a marketplace add-on that isn’t visible from the outside but is entirely visible to the competitor’s actual customers. The comparison sheet is a snapshot with no expiration date printed on it, presented as though it were current.

The pricing rows compound the distortion in a specific, predictable direction. List price for the competitor, negotiated or promotional price for the vendor doing the presenting, is close to the default comparison method, and it isn’t dishonest in the narrow sense, both numbers are real, but it compares two different stages of the same negotiation, one that hasn’t happened yet against one that has. A prospect who hasn’t negotiated with either vendor is looking at the least favorable version of one price and the most favorable version of the other.

Feature checkmarks suffer the same collapse the Security Theater Demo’s checklist suffered. “Supports multi-currency” or “has a mobile app” is either true or false on the slide, with no room to indicate that one vendor’s version is a fully native capability and the other’s is a third-party add-on with a separate contract, a separate support line, and a separate bill.

Why it works on smart people

A side-by-side comparison has the visual grammar of objectivity. Two columns, symmetric formatting, a neutral-looking checkmark or X, all of it borrows the credibility of a spec sheet or a lab test, something that feels like it was measured rather than argued. The room’s guard is lower here than almost anywhere else in the demo, precisely because the format looks like data rather than persuasion, even though the party assembling the data has an obvious and undisclosed conflict of interest in every cell.

There’s also a research-avoidance effect. Verifying even a handful of rows against the competitor’s actual current documentation, or a call with their team, takes real time that a sales cycle often doesn’t budget for, and the comparison slide offers a shortcut that feels like due diligence without requiring any. Accepting the slide as accurate is the path of least resistance, and it’s a path built specifically to be the easiest one to take.

The actual damage

This is the one that produces a decision built on a comparison that was already stale, sometimes badly, by the time the contract was signed. A capability marked absent for the competitor that had actually shipped means the losing vendor was disqualified on a false premise, and the winning vendor’s genuine advantages, whatever they actually were, never had to be defended on their own merits because the comparison did the work for them.

Once implementation starts, the gap between the comparison sheet and reality becomes the buyer’s problem, not the vendor’s. If the deciding factor was a feature gap that didn’t actually exist, the buyer is now living with a vendor selected on the wrong basis, discovering the real trade-offs only after the switching costs have become substantial.

The fix, if you’re the one presenting, or the one buying

If you’re presenting, date every comparison row and be specific about the source, and if there’s a real chance a competitor has closed a gap since, say so rather than let a stale advantage stand unchallenged. If you’re buying, treat any vendor-supplied comparison as a hypothesis to verify, not a finding to accept. Take the three or four rows that would actually change your decision and check them directly against the competitor’s current documentation or a live conversation with their team, rather than checking all thirty rows equally or none of them at all.

A comparison chart built by one side and verified by neither side is not a comparison. It’s an argument wearing a spreadsheet’s clothes, and it deserves exactly the scrutiny an argument gets, not the trust a measurement earns.


The Waterdeep Trading Company runs on the same principle at its literal gates. In Receiving Controls That Stop Bad Goods, nothing becomes sellable stock on the strength of a seal or a claimed count alone. It gets checked at the gate, every time, regardless of who’s vouching for it. A competitive comparison deserves the same standing policy: verify before it enters the decision, not after.