&mdash; A Tinkerers Notebook

By Business Systems & AI | Tinkerer, Storyteller, Author & Trainer | Canine and Equine Choreographer | Technology Specialist at Microsoft

The Sixty-First Floor, with Ines Calder

Previously: The owners of the Hargrove Building hired Ines Calder to find out why its elevator recognizes a sixty-first floor that no permit admits exists, after a night guard rode up to it and never came back down. She took the retainer, rode up with her team, the goat included, and followed the sound of a clicking radio out into the hallway just as the elevator doors closed behind them.

Ines rapped twice on the door frame and the floor held her, and she was already three steps down the hall before she looked back to see if the others had followed. Hatch had a boot wedged in the closing doors, and the doors did not care. They shoved against her ankle until she pulled it free, and the car dropped away with a sound like a held breath let go.

“That’s one way to lose an elevator,” Hatch said.

“We didn’t need it,” Ines said, and kept walking toward the clicks.

The hallway ran longer than the building’s footprint should have allowed, and Dov, counting under his breath, gave up somewhere past twenty. None of the doors had numbers, brass plates, or the little paper slots some buildings used for a name card. Every few feet another door stood exactly like the last one, and Leland tried three handles before finding one that turned.

The room behind it had a bed that had been slept in, a stack of paperbacks with cracked spines, and a kitchen counter with two mugs on it. One mug was empty. The other sat next to a radio with its channel light still on, two short clicks and a pause coming out of it steady as a pulse, and when Dov touched the side of the mug it was warm.

“Someone left in a hurry,” Dov said.

“Or someone’s still here,” said Leland, and nobody answered that.

Buttress would not cross the threshold, and stood in the hallway with his bell silent, watching the door the way he watched a floor he did not trust. Ines picked up the radio and turned it over, looking for a maker’s mark or a serial number, and found the panel smooth and blank where one should have been. She thought about the panel in the elevator, sixty floors and then a sixty-one where the brass had been bare.

Hatch went to the window and pulled the blind an inch. Outside was not the city. It was a courtyard, four stories down, lit by lamps that did not match anything on the block Ines remembered walking in on.

“I’d like everyone to notice we don’t have an elevator,” Hatch said.

“I noticed an hour ago,” Ines said, though her watch read four minutes since the doors had closed.

The radio clicked twice more and went quiet, and from somewhere down the long hallway another radio answered it, clicks coming back the other way, two short and a pause, moving closer.

The Vote

What does the team do next?

Vote in the LinkedIn poll, and Episode 3 gets written from whatever wins.

Stay together: The team moves as one group toward the answering clicks.

Split up: Half the team follows the clicks while the rest search the nearby rooms.

Barricade the room: They lock the door and wait to see who is knocking back.

Send Buttress ahead: He is the only one who has not been wrong about a floor yet.

Episode 1: The Plate Says Sixty

By Business Systems & AI | Tinkerer, Storyteller, Author & Trainer | Canine and Equine Choreographer | Technology Specialist at Microsoft

The Sixty-First Floor, with Ines Calder

Ines Calder counted the retainer twice, standing at the lobby desk of the Hargrove Building at five past four in the morning while the owner watched her do it. It was in a bank envelope, and it was all there. She put it inside her jacket and looked at the elevator, which had a brass plate above the buttons that said sixty floors.

“Can you make it stop?” said Pell, who owned the building with two cousins in Connecticut.

“That depends whether you want it stopped or gone,” Ines said.

“It was inspected in March,” said Pell.

The fire marshal had a certificate of occupancy in a plastic sleeve, and he read from it twice: sixty floors. The night guard, Ostrander, had ridden the elevator up at 2:14 a.m., and the car had come back down empty. At the dispatch desk his radio had been keying ever since, two short clicks and a pause, two short clicks and a pause.

Dov Abelard had taken the controller log from the building engineer and was reading it under the lobby’s one good lamp, moving a pencil down the column. Hatch Pruitt, who had flown salvage runs until one in the morning, sat on the base of the security desk with her boots crossed and her eyes shut. Leland Cho stayed by the front doors with Pell and the marshal and asked them, in turn, about their weekends.

Buttress stood on the marble in the middle of the lobby, and the bell on his leather collar rang once each time he shifted his weight. He had refused the carpeted runner by the mailboxes and the stairs to the mezzanine, and he had crossed the marble without hesitating. Ines trusted his opinion of a floor over any inspector’s she had ever paid.

“The controller logged the car at sixty-one,” Dov said, and turned the page.

“Is the goat coming?” Hatch asked, without opening her eyes.

“He goes where the floor holds,” Ines said.

The lobby car left at 4:31 with four passengers, one of them on hooves. Ines pressed sixty and held it until the light behind the button went steady. Nothing rattled and nothing slowed, and above the sixty on the panel, where the brass had been bare, a sixty-one lit up.

“I’d like it on record that I said,” Hatch began, and the doors opened.

The carpet in the hallway was the color of wet slate, and it was damp. Buttress held one hoof over it and set it back on the car floor. From the far end of the hall came two short clicks and a pause. Ines rapped twice on the door frame and stepped out, and the floor held her. Behind her the doors began to slide shut, and Hatch got a boot in the gap.

The Vote

What does Ines do next?

Vote in the LinkedIn poll, and Episode 2 gets written from whatever wins.

Follow the clicks: Ines heads straight down the hall toward the sound.

Try the nearest door: Ines opens the first door she passes and looks inside.

Hold the elevator open: Hatch and Ines try to keep the car at sixty-one so it cannot leave.

Send the goat back down: Buttress rides the car to the lobby alone while the others explore.

ERP Fraud Files, Part 13: More Than 245 Transfers to Accounts the Senior Accountant Controlled

By Business Systems & AI | Tinkerer, Storyteller, Author & Trainer | Canine and Equine Choreographer | Technology Specialist at Microsoft

Mandy Urban made more than 245 transfers out of her employer's bank accounts and into accounts she controlled, $1,115,344.73 in all. She was a senior staff accountant at a Charlotte company from January 2019 to June 2022. She pleaded guilty to wire fraud in March 2024 and was sentenced in February 2026 to 41 months in prison followed by two years of supervised release.

What happened

Her job covered a lot of ground. According to the U.S. Attorney's Office, she maintained the company's general ledger and prepared its financial statements. She also reconciled the accounts, bank statements included.

Divide $1,115,344.73 by 245 and you get about $4,552. The release says "more than" 245 transfers, so the real average sits lower. Then, in the release's words, she "falsified the company's books and records to conceal the scheme."

The release also lists two Florida convictions. In 2015 she was sentenced to five years of supervised probation for grand theft of about $135,000. In June 2022 she was sentenced to two years in prison for a different scheme to defraud. June 2022 is also the month her employment at the Charlotte company ends in the release's timeline. It does not say how that employment ended, or whether the two are connected.

Why the gap existed

In a company where the controls work, the ledger, the financial statements built from it, and the bank reconciliation check one another. Here one person held all of them. The release doesn't mention anyone else reviewing her work.

A bank transfer to an account that belongs to no vendor and no employee is a detectable event, provided something compares outgoing destinations to the master files. More than 245 of them is a pattern, however small each one was.

The 2015 conviction predates her start date by four years. It was public record on her first day. The release doesn't say whether anyone looked.

Controls that would have caught it

Keep bank reconciliation away from whoever posts to the ledger. The person who reconciles the cash accounts should not be able to post to them, and should work from statements that come straight from the bank. Preparing the financial statements is a different job again, which belongs to a different person where headcount allows and to an outside reviewer where it doesn't.

Match every outgoing transfer destination to the master files. A transfer needs a payee that exists in the vendor or employee records, with the account approved by someone other than the person releasing the payment. A new destination account should trigger a notification, not pass as a quiet setup step.

Screen finance hires, and rescreen them, with the results held outside finance. Anyone with bank access or ledger rights gets a background check before the first day and again at set intervals, within whatever the law allows where the company operates. The results go to HR or ownership.

An AI prompt example for ERP fraud detection

This case calls for one query about destinations and one about who did what. Against an ERP's cash management and general ledger modules, an auditor could run something like:

"List all outgoing bank transfers over the last four years where the destination account does not match a bank account on any vendor, employee, or customer record."

A second query goes after the overlap in duties:

"List every user who both posted journal entries to a cash account and completed the bank reconciliation for that same account, by period."

Neither query needs a suspect. Both need the master files to be current, which is its own project.

The pattern for this series

Parts 5, 7, 10 and 12 each had one person who kept the books and could edit them. Urban makes five. What is new here is a theft conviction on record four years before the first day of work. Part 12 raised the question of whether anyone knew about an earlier theft, and this release is just as quiet.

Source disclaimer

The case details in this article are drawn from a press release published by the U.S. Attorney's Office for the Western District of North Carolina, 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, Western District of North Carolina. Press release on the sentencing of Mandy Deann Urban for embezzling from her employer, February 2026. https://www.justice.gov/usao-wdnc/pr/twice-convicted-accountant-sentenced-embezzling-more-11-million-employer

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.

Autopsy #29: The Discovery-Free Demo

By Business Systems & AI | Tinkerer, Storyteller, Author & Trainer | Canine and Equine Choreographer | Technology Specialist at Microsoft

Cause of death: the demo opened with the vendor’s standard ninety-minute walkthrough, and nobody had asked the buyer a single question about how their month-end actually runs.

The first slide is an agenda with five lines on it: platforṃ overview, finance, supply chain, reporting, questions. Not one line ṃentions the buyer. The sales engineer has delivered this walkthrough so ṃany times he could do it with the screen turned off, and at 9:02 he starts to.

Nobody asked the buyer anything beforehand. Not how ṃany legal entities they run, not how long their close takes, not what the old system did that finally made someone open a vendor search. The ṃeeting exists because a form got filled in and a calendar invite went out.

What actually happened

Discovery gets skipped for reasons that all sound sensible froṃ the seller’s chair. The buyer’s calendar is tight. The demo slot is the thing that got booked. The internal contact says “just show us what it does,” and the quarter is eleven weeks long, not twelve.

So the vendor falls back on the standard script, which was built to survive any audience and is therefore tuned for none of theṃ. The finance director who inherited a broken intercoṃpany process sits through the whole procurement module. The warehouse lead gets a general ledger tour.

Why it works on smart people

A polished walkthrough looks like preparation. Questions coṃe from the room, the engineer answers them fluently, and fluency reads as depth. The buyer has no way to know what the right deṃo would have covered, so a confident answer to a question they happened to ask feels like fit.

The seller ṃakes the mirror-image mistake. Polite attention reads as interest, and nobody in a deṃo room walks out angry. That’s the trouble with this one. Nothing visibly goes wrong, so nothing gets corrected.

The actual damage

The follow-up goes quiet. When the vendor asks for feedback, the buyer says it looked great and they’ll circle back, because there’s no objection to naṃe. There’s only a feeling that the ninety ṃinutes weren’t about them, and that’s hard to put in an email to someone you might still buy from.

Meanwhile another vendor spent its first ṃeeting asking questions and showed three things. It gets the second ṃeeting.

The fix, if you’re the one presenting

Make discovery a condition of the deṃo slot, not a favor. Ask for forty-five ṃinutes beforehand, and if the buyer won’t give it, open the demo with ten minutes of questions and say why you’re doing it. Then rebuild the agenda in the buyer’s words, using the three probleṃs they actually described, and cut everything else.

Tell the rooṃ what you’re leaving out. “You didn’t ṃention purchasing, so I’m skipping it unless you want it back” is one sentence, and it’s the clearest signal anyone in that room will get that somebody was listening.

The fix, if you’re the one buying

Send your three worst processes to the vendor in writing before the deṃo, and ask them to show those. Watch what they do with it. A vendor that turns up with the standard deck anyway has told you how the iṃplementation will go.

If nobody has asked you anything by the tiṃe the agenda slide goes up, say so at minute five, out loud. Redirecting a deṃo costs a little awkwardness. Sitting through the wrong one costs ninety ṃinutes and a second meeting you didn’t get.

Next in the series: Autopsy #30, The Empty Chair Demo, where the person who signs the check was never invited, so the room approved something it couldn’t buy.

For more on the vendor’s preferred route standing in for the buyer’s actual process, see Autopsy #1: The Golden Path Demo.

Stop Giving Everyone the Same Forty Questions

By Business Systems & AI | Tinkerer, Storyteller, Author & Trainer | Canine and Equine Choreographer | Technology Specialist at Microsoft

I sat Microsoft’s AB-100 exaṃ last Friday, and I am still a little salty about it. This is the Agentic AI Business Solutions Architect exaṃ, a test about designing AI agents, and it was delivered in a format that couldn’t ask me a single follow-up question.

Which is how I ended up thinking about nurses.

The NCLEX, the exaṃ every nurse in the United States passes before getting a license, can end after 85 questions. It can also run to 150. Two candidates sit down at the saṃe testing center on the same morning, and one walks out well before the other. Neither of them failed early. The test siṃply stopped once it was sure.

Coṃpare that to the end-of-course assessment most ERP training programs still ship. Forty multiple-choice questions, the same forty for everyone, written by whoever drew the short straw the week before go-live. The accounts payable clerk who has run the systeṃ for a decade and the new hire who started Monday both answer “What is the purpose of a posting profile?” One of them is bored. The other is guessing, and the score that coṃes out the other end tells you almost nothing about either.

The machinery already exists

Adaptive testing has been around for decades under a fairly literal naṃe: Computerized Adaptive Testing. The GMAT picks each question based on how you handled the one before it. The GRE works at a coarser grain, using your perforṃance on one section to set the difficulty of the next.

Underneath sits Iteṃ Response Theory. Every question in the bank carries a ṃeasured difficulty, established by running it past real test takers before it ever counts toward anyone’s score. The algorithm estimates your ability, serves whichever question will tell it the most about that estimate, and updates. When the ṃargin of error gets small enough, it quits.

So why doesn’t corporate training use it? The bank. A calibrated item bank means hundreds of questions, each piloted on enough people to pin down how hard it actually is. Nobody building a D365 rollout curriculuṃ has that budget or that many volunteers, and by the time they did, the next release wave would have moved the button half the questions ask about.

What changes with a language model

A language ṃodel doesn’t need the bank. It can write the next question on the spot, aiṃed at wherever the last answer suggested the person stands. That ṃakes the whole thing less like a quiz and more like an oral exam, the kind where the examiner keeps pushing until you run out of road.

But “ask harder questions” is not a design. Blooṃ’s taxonomy at least gives you rungs: remember, understand, apply, analyze, evaluate. In D365 terms the ladder might start at “What is three-way matching?” and move to “Why would a vendor invoice fail it?” A few rungs up, an invoice is blocked because the ṃatch policy on the vendor overrides the one in Accounts payable parameters, and the candidate has to explain where they would look and why.

The Dreyfus ṃodel, from Stuart and Hubert Dreyfus’s work around 1980, describes the move from novice to expert as a shift from following rules to exercising judgment. That ṃatters for question design. Junior questions have answers. Senior questions have trade-offs, and the useful signal is whether the person notices theṃ at all.

Knowledge Space Theory is the one ṃost trainers haven’t heard of, though ALEKS has used it in math courses for years. It ṃaps which concepts depend on which. If soṃeone can’t explain posting profiles, there is no point asking about intercompany settlement, and an adaptive interview should know that before it asks.

Where it goes wrong

Consistency goes first. Two people at the saṃe level can get very different questions, which makes their scores hard to compare and harder to defend when someone in HR asks how the number was produced.

Then there’s fluency. An articulate beginner can sound ṃore competent than a terse expert, and language models tend to grade generously. The consultant who answers in two crisp sentences can lose to the one who wrote a confident paragraph of nonsense.

And the ṃodel can simply be wrong about D365. Ask it to judge an answer about settleṃent behavior and it may “correct” a candidate who had it right, with exactly the same tone it uses when it’s correct.

The version worth building

Split the job in two. The structure stays fixed, written by soṃeone who knows the module: a competency map, plus a rubric for each level that spells out what a good answer contains. The model works inside that frame, generating questions at the current level and pressing with follow-ups when an answer is thin. A separate grading pass, with no ṃemory of how pleasant the conversation was, scores each answer against the rubric.

Keep the transcripts. If the result feeds anything with consequences, like certification or who gets put on the cutover teaṃ, a human should read a sample of them.

It also ṃaps naturally onto a leveling system, if you lean that way. “Level 7 in Accounts payable” ṃeans something a percentage never did, and a learner who topped out on three-way matching can see the exact question that stopped them.

ERP Fraud Files, Part 12: The CFO Who Deleted 3,800 Credit Card Charges From the Expense System

October 5, 2026

By Business Systems & AI | Tinkerer, Storyteller, Author & Trainer | Canine and Equine Choreographer | Technology Specialist at Microsoft

More than 3,800 company credit card charges were deleted from an expense-reporting system, and the person who deleted them was the chief financial officer. Tina Feuerstein, 53, of Hanover, Pennsylvania, ran finance at a Pennsylvania subsidiary of a Chicago-area company. A federal jury in Chicago convicted her on April 9, 2026, of eight counts of wire fraud after a four-day trial. Sentencing was set for August 26, 2026, and none of the sources used here report the outcome.

What happened

Prosecutors say Feuerstein used a company credit card for personal spending over roughly five years, more than $1 million in all, much of it on luxury furniture and designer clothing. The charges were the easy part. A card issuer bills what it bills. The hard part was the paper trail inside her own company, so she deleted the charges from the expense-reporting system and falsified entries in the general ledger to cover what was left.

Then she prepared consolidated financial statements that, according to the government, misrepresented the company's expenses. Those statements went up to the owners.

Evidence at trial also showed that she had previously embezzled more than $250,000 from another employer.

Why the gap existed

Most earlier cases in this series involved someone getting past a control or around one. This one is simpler. The person responsible for the books also had the ability to remove records from the system that was supposed to check spending against them. Deleting a charge from an expense report doesn't change what the card issuer billed. It changes what the company sees, and if the only record management reads is one she could edit, her edits are the record.

A subsidiary makes that worse in a particular way. Consolidated statements travel upward to owners who rely on the finance function to tell them what happened, and at this company the finance function was her. The sources don't say who, if anyone, reviewed her own card activity.

They also don't say whether anyone at the subsidiary or its parent knew about the earlier theft when she was hired.

Controls that would have caught it

Delete rights removed from anyone who holds a card or posts to the ledger. An expense line that has to come out gets voided or reversed, with the original preserved, a reason code, and a second person's approval. Under that rule, 3,800 deletions would have left 3,800 reversals to look at.

Card issuer statements reconciled by someone outside accounting. The issuer's monthly statement is the one document she couldn't edit. Match it line by line against the expense system and the ledger, and chase every charge that has no counterpart.

Review of the CFO's own spending by someone above the CFO. Whoever approves the finance head's card activity can't report to the finance head. At a subsidiary that probably means the parent's controller or the owner's finance team.

An AI prompt example for ERP fraud detection

This case calls for a query about what is missing, not what is there. Against an ERP's expense management and general ledger modules, paired with the card issuer's transaction feed, a controller or auditor could run something like:

"Compare every transaction on the corporate card issuer's feed against the expense reporting system and the general ledger for the last six years. List each issuer charge that has no matching record, or whose matching record was deleted or voided."

A second query goes after the people with delete access:

"List all deleted or voided expense lines by the user who deleted them, and flag any user who deleted lines on a card assigned to that same user."

Neither asks anyone to guess at motive. Both ask the system to show what used to be there.

The pattern for this series

Part 5 was a controller forging bank statements. Part 7 was a payroll manager keeping separate general ledgers. Part 10 was a bookkeeper editing the school's accounting files. This is the fourth time in the series that the person keeping the books could also edit them, and here the owners upstream read the consolidated version.

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. This article reports a jury verdict; 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 Illinois. "Former CFO of Chicago-Area Company's Subsidiary Convicted of Embezzlement." Press release, April 2026. https://www.justice.gov/usao-ndil/pr/former-cfo-chicago-area-companys-subsidiary-convicted-embezzlement

CFO Dive. "Ex-CFO embezzled $1M for luxury purchases, Chicago jury finds." https://www.cfodive.com/news/ex-cfo-embezzled-1m-luxury-purchases-chicago-jury-finds/818232/

Patch. "CFO Embezzled $1M From Employer To Buy Designer Clothes, Chicago Jury Finds." https://patch.com/illinois/chicago/cfo-embezzled-1m-employer-buy-designer-clothes-chicago-jury-finds

Autopsy #28: The Credit Hold Demo

October 5, 2026

By Business Systems & AI | Tinkerer, Storyteller, Author & Trainer | Canine and Equine Choreographer | Technology Specialist at Microsoft

Cause of death: the demo customer never came within shouting distance of their credit limit, and the hold-and-release workflow built to catch that never once had to run.

The sales order is for $18,400, the custoṃer has a $250,000 credit limit, and the screen shows a green checkmark and a balance that barely moved. The sales engineer mentions that if the order pushed the customer over the limit, the system would place it on hold automatically and route it to a credit manager for release. He says it with a little hand gesture, the way people describe a door they have no intention of opening. Everyone nods. The order ships.

That hold-and-release path is the feature the finance teaṃ came to see, and the only evidence for it in the room is a sentence.

What actually happened

A credit hold is a sṃall piece of logic with a lot of edge cases hanging off it: orders that cross the limit by a dollar, partial shipments against a held order, a customer who pays on the 29th and whose payment hasn’t posted by the 28th, a salesperson who needs the hold released at 4:55 on a Friday. Deṃo data doesn’t contain any of that. It contains one custoṃer with a large limit and a small balance, because that customer never causes anything to go wrong.

So the hold fires in the deṃo only if someone forces it, and nobody forces it. The workflow is described instead of shown, and described workflows have a way of sounding finished.

Why it works on smart people

The feature is real. That’s the trouble. The system does place orders on hold when a limit is exceeded, and a buyer who asks “does it support credit holds?” will get a truthful yes. What the yes doesn’t cover is who gets notified, how long a held order sits before anyone notices, whether the liṃit check includes open orders not yet invoiced, and whether a release by one manager leaves an audit trail the controller will accept.

Those are policy questions dressed as software questions. The deṃo can’t answer them because the demo company has no policy yet. It has a checkbox.

The actual damage

At go-live, the credit liṃits get loaded from a spreadsheet, and a few customers turn out to be over theirs on day one. Orders stack up in a hold queue that nobody was assigned to watch. Sales finds out when a custoṃer calls to ask where their pallet is, and finance finds out when sales stops speaking to them.

Then the workaround arrives: soṃeone raises every limit to a number large enough that nothing holds. The feature is still switched on and the report still says credit control is autoṃated. The control is gone.

The fix, if you’re the one presenting

Force the hold. Pick a custoṃer already sitting at ninety-five percent of their limit, enter an order that tips them over, and let the room watch the order stop. Then show who receives the task, how a release is recorded, and what the sales rep sees on their end while they wait.

Say what the check counts: invoiced balance only, or open orders and unposted payṃents too. That one sentence settles an arguṃent the buyer would otherwise have with themselves at go-live.

The fix, if you’re the one buying

Bring your own worst custoṃer. Naṃe the account that has been over its limit since March and ask to see its order held, released, and audited in the demo environment. If the vendor needs a week to configure that, the feature is a week away froṃ being something you can evaluate.

Ask who owns the hold queue on day one, and write the naṃe down before you sign. A control with no assigned owner is a report that nobody reads.

Next in the series: Autopsy #29, The Bank Reconciliation Demo, where the auto-match rate hit one hundred percent because the demo bank feed was generated from the ledger it was being matched against.

For more on a feature that looks fine until real volume arrives, see Autopsy #8: The Performance Demo.

ERP Is from Mars, CRM Is from Venus

October 5, 2026

By Business Systems & AI | Tinkerer, Storyteller, Author & Trainer | Canine and Equine Choreographer | Technology Specialist at Microsoft

Closed, according to whom

An opportunity flips to Won in Dynamics 365 Sales. Over in Finance and Operations, nothing has happened yet: no sales order, no invoice. Sales says the deal closed. Finance says it didn’t, and neither of them is lying.

The usual explanation borrows from the old self-help shelf: ERP is from Mars, CRM is from Venus. It’s a good line. It’s also too generous, because it implies the two camps just have different personalities and could get along with a little counseling. The gap is grammatical. CRM talks in the future conditional, ERP talks in the past perfect, and neither system was ever taught to conjugate in the other’s tense.

CRM: what might happen

Everything in a CRM is a maybe with a number attached. An opportunity carries estimated revenue and a probability, and its close date is a guess that slides every time the buyer’s procurement department goes quiet. Multiply revenue by probability across the pipeline and you get a weighted forecast. Useful to a sales manager. Meaningless to a general ledger.

The vocabulary follows from that: relationships, calls, champions, next steps. A win is a statement of intent (the customer has said they mean to buy), and a loss gets a reason code and then mostly sits there, since a lost opportunity triggers nothing downstream. Nobody in sales thinks of a won deal as provisional.

ERP: what has happened

ERP doesn’t believe anything until it’s posted. A sales order in Finance and Operations is still soft; you can change the quantity or the price. Post the invoice and the record hardens. You don’t edit a posted invoice, you issue a credit note, and you don’t fix a posted journal, you reverse it and post a new one. The ledger keeps the mistake and the correction side by side, permanently, because the point of the thing is that the past stays where you put it.

Even the customer is a different animal. In CRM an account is a web of people, from the champion who pushed the deal through to the contact who left in March and is still on the newsletter list. In ERP a customer is a party with a customer group, payment terms, a credit limit and a posting profile that decides which ledger accounts get hit. Same company. One system wants to know who to call; the other wants to know whether they’ll pay.

The tense nobody owns

Between the two sits the present progressive, and it belongs to operations. A sales order released to the warehouse is no longer a possibility, and it isn’t a fact on the ledger either. Inventory is reserved. A wave is being picked. Half the order ships today and the rest is waiting on a purchase order that’s waiting on a vendor.

This is where integration projects tend to bleed. CRM stopped paying attention the moment the opportunity closed, and ERP won’t fully commit until the invoice posts, so the in-between state has no real owner. The rep asks customer service, customer service asks the warehouse, and the warehouse checks a screen the other two can’t see.

The handoff

Quote to sales order is where the two dictionaries collide. In the Dynamics stack, dual-write is Microsoft’s attempt at a shared vocabulary. It syncs Dataverse tables with Finance and Operations entities in near real time, so an account in Sales maps to a customer in F&O and a won quote can become a sales order without anyone retyping it.

Anyone who has configured it knows the field maps are the easy part. The hard part is that the two sides disagree about when a record is allowed to exist. CRM wants a customer the moment someone sounds interested. ERP wants a customer group and a credit check before it will take the call, and a prospect created in Sales with half its fields empty is exactly the kind of record that stalls a sync. Products with variants are their own afternoon.

When the future is allowed to become the past

ASC 606 is, among other things, a rule about tense. It decides when a promise to a customer becomes revenue, and the answer is when the performance obligation is satisfied, not when the rep rings the bell. IFRS 15 says much the same outside US GAAP. Sales celebrates the signature. Accounting waits for delivery, and on a subscription or a bundled deal it may wait for months, recognizing the revenue a slice at a time.

Forecasting is the one place the two tenses are forced to share a sentence. In theory the weighted pipeline from CRM is what demand plans and cash forecasts in ERP should be built on. In practice that means finance is planning around probabilities a sales rep typed in, and finance hates that. Supply chain hates it more, because they’re the ones holding the inventory when a 70 percent deal slips a quarter.

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

October 2, 2026