How counting works, when it bites, and the reconciliation calendar that turns a submission into a decision. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session seven of forty. Last week we took apart the enrollment, the layer where your commercial deal actually lives, and we ended with five structural decisions that set three years of pricing before anybody says the word discount. Today the enrollment goes into operation, because once a year it does something: the annual order, and with it the true up. Here is the sentence that governs the whole session, and it comes straight out of session two: the number you report becomes the floor for the rest of the term. There is no downward step. So the true up is not an administrative submission, it is an annual commercial decision that most estates delegate to whoever has admin centre access and two spare afternoons. Today: the mechanics, what actually gets counted and why the admin centre is not the enrollment, the ninety day reconciliation calendar, the reclamation pass, and the timing decisions that change what a true up costs. Let's count properly.
Five takeaways. One, the mechanics: what the annual order is, what gets reported, and the fact that the billing simply follows from a number you supplied. Two, the counting: which populations and products are actually in scope, and the gap between what your admin centre displays and what your enrollment asked for, which is where most of the money in this session sits. Three, the calendar: ninety days, four phases, and why starting in the last fortnight guarantees you report problems rather than fix them. Four, the reclamation pass: the four populations to find before you count, leavers, duplicates, service identities, and over provisioned roles. And five, the timing: seasonal peaks, project onboarding, and the anniversary date itself, all of which are scheduling decisions with three year price tags. One framing before we begin: nothing in this session is about reporting less than you have. Every genuine user gets reported. It is about reporting the right number, which is a different discipline entirely.
The mechanics, five steps at each anniversary. The count: you establish the additions since your last order, per the profile definition from session six, and notice the word you, because this is a self report. The submission: the count goes in through your licensing solution provider, and both the accuracy and the timing of it are yours to control. The order: your additions bill at your contracted rates for the remaining term, which is the EA genuinely working in your favour, growth is cheap inside one, and in a market that moved eleven to nineteen percent across two waves that protection is worth real money. The new baseline: the reported quantity becomes the floor going forward, permanently, because there is no downward step. And the invoice, which is a treasury question decided separately from the count. Now look at that list again and notice which parts you control: the accuracy of the count, and when the count is taken. Both happen before anything is submitted. Everything after the submission is arithmetic performed on a number you supplied, which means essentially all of your leverage in this process sits in the ninety days beforehand.
What gets counted, and the distinction that matters most in this session: the admin centre is not the enrollment. What the admin centre shows you is licences assigned to accounts. It is entirely accurate about that and it knows nothing else. It does not know whether an account belongs to a current employee, someone who left in March, a service integration, a test tenant from a migration two years ago, or the same human being with two identities after a domain change. It counts objects. What the enrollment asks for is qualified users or devices, per the profile definition, which has exclusions, entity scope, and category rules, and which counts a defined population rather than a set of objects. The gap between those two numbers is your reclamation opportunity, and in my experience it is rarely small: estates routinely find leaver accounts, orphaned service identities, and duplicates measured in the hundreds rather than the dozens. So the instruction is precise: report the enrollment's number, evidenced by your own reconciliation, rather than the console's number taken at face value. Both are honest numbers. Only one of them is what the agreement asked you for.
First check. Two weeks before your anniversary, the admin centre shows five thousand three hundred and forty assigned E3 licences, against four thousand nine hundred reported last year. The first action: A, report five thousand three hundred and forty, it is what the system shows and accuracy matters. B, reconcile the four hundred and forty delta first: identify leavers, duplicates, service accounts, and genuine new hires separately, because the reported number becomes the floor for the rest of the term. C, report last year's number and reconcile afterwards. Or D, ask your provider to estimate the correct figure. Pause here. What happens to a reported number after it is submitted, and for how long?
The answer is B, and the key insight is that four hundred and forty is not a number, it is four different populations wearing one total. Genuine new hires, who must be reported. Leavers, who should have been removed at exit and were not. Service and test identities, which may not be qualified users at all depending on your profile. And duplicates from identity work, where one human appears twice and both records look entirely legitimate. Only the first group belongs in your true up, and since there is no downward step, whatever you report gets paid for in every remaining year of the term, so a four hundred and forty seat error on a three year term is not one mistake, it is three payments. A confuses the console's accuracy with the enrollment's question, which is session six's distinction arriving under time pressure. C is straightforwardly wrong and I want to be unambiguous about it: under reporting a genuine addition is a compliance exposure, and the correct answer is never to misreport in either direction. D outsources your own count to a party whose margin sits inside the transaction, and who cannot see your HR data anyway. Reconcile, document, then report the accurate number.
The reconciliation calendar, ninety days, four phases plus the submission. T minus ninety: pull assigned licences and sign in activity per product, and start here because extraction and access approvals reliably take longer than anyone plans for. T minus sixty: reconcile against HR, leavers, movers, contractors ending, and start early because HR data arrives on its own schedule regardless of your anniversary. T minus forty five: reclaim, deprovision, remove duplicates, resolve the service accounts, and note that changes need time to settle before a count is taken. T minus twenty one: take the count, document the basis, review the exclusions, because a documented count survives questions asked two years later by people who were not there. And T minus seven: submit, with the working papers filed. Now the sentence that justifies the entire slide: run in the last fortnight, this is a submission, you report what you find. Run across ninety days, it is a decision, you fix what is wrong first. And the difference between those two is not a one off saving, it is money that recurs in every remaining year of the term. Our guest analyst put a number on exactly that difference.
Guest analyst The clearest before and after I have on true ups came from the same client, two consecutive years, which is why I keep using it. Year one, I was not involved. Their anniversary was in June, the count was pulled in the last week of May by a systems administrator who did exactly what he was asked, and they reported an increase of about six hundred and twenty users. Perfectly honest, entirely accurate as a description of what the admin centre showed. Year two, we ran the ninety day calendar. Started in March, pulled the data, matched it against HR, and the six hundred and twenty from the previous year turned out to have contained roughly two hundred and forty accounts that were not qualified additions at all: leavers who had never been deprovisioned, about sixty duplicates from a domain consolidation, and a batch of test identities from a project that had finished. Those two hundred and forty had been sitting in the committed baseline for a year, and they stayed there, because there is no way to take them back out. That was the cost of the fortnight. In year two, having reconciled first, the reported addition was three hundred and ten rather than the five hundred and forty the console would have suggested. Same business, same growth, different process. The ninety days cost them about four days of one analyst's time. So when somebody tells me the true up is administrative, I ask them what their finance function would call a recurring annual payment nobody reviewed. Because that is what it is.
Two hundred and forty non qualified accounts committed for a term because the count was pulled in the final week, and the fix cost four days of one analyst's time. What would your finance function call a recurring annual payment nobody reviewed? Second check is that scenario, arriving late.
Check two. Your reconciliation finds three hundred and eighty assigned licences with no sign in for over a hundred and twenty days. Reclaiming them properly takes three weeks of coordination with business units. Your anniversary is in ten days. What do you do? A, report the three hundred and eighty, there is no time to reclaim them properly. B, exclude them from the count anyway and reclaim afterwards. C, report accurately this year, start the reclamation immediately, and move the calendar so next year's count is taken after the reclamation rather than before: one year of an inherited problem, then permanently fixed. Or D, ask Microsoft for an extension to the anniversary. Pause here. What is true about the count on the day it is taken, and what is true about the calendar for next year?
The answer is C, and it works by separating two problems that feel like one. On the day the count is taken, those three hundred and eighty licences are assigned. That is a fact, so reporting them is the accurate answer, and B is misreporting whatever the intention behind it, which trades a one year cost for a compliance exposure that module seven will show you is a bad trade at any size. But A stops one step short of the right answer, and this is the part I care about: it accepts the number and does nothing about the cause, which guarantees the identical conversation next year, and the year after that. C reports accurately now and then fixes the process permanently, so that the reconciliation precedes the count from here on, and the fix costs nothing beyond a calendar entry with an owner attached. That is Tom's four days of analyst time, spent once, changing every subsequent year. And D asks the vendor to solve a scheduling problem that is entirely yours: anniversaries are contractual, but the window you actually want extended is next year's reconciliation, which you can schedule yourself this afternoon.
The reclamation pass, four populations to find before you count. Leavers: accounts belonging to people who have left, and where the joiner mover leaver process does not remove licences at exit they accumulate silently and get counted as headcount, which is the single largest category in most estates. Duplicates: one human with two identities, from a migration, a merger, or a domain change, counting twice while both records look entirely legitimate to anyone checking. Service and test identities: integration accounts, test tenants, training shells, and whether they are qualified users is a profile question from session six, so get the answer written down once rather than re argued every year by different people. And over provisioned roles: people holding a tier they do not use, which is strictly a mix question rather than a count question, module three prices it properly, but the anniversary is when the evidence is freshest and the data is already extracted, so note it while you are there. And the discipline in the last line matters more than the list: this pass belongs before every anniversary, not before every renewal. Annual reclamation is a fraction of the work and finds problems while they are still small enough to fix quietly.
Timing decisions, because the mechanics are fixed and the scheduling around them is yours. Seasonal populations: a peak landing near your anniversary commits for the remaining term, which is session two's logistics business and its two million dollars, and where a seasonal wave is genuinely unavoidable the answer is to provision it on a lighter tier or on a different vehicle entirely, per session four's split, so it never enters the committed count. Project onboarding: a large project team going live the month before an anniversary is a decision with a three year price attached, and where the timing has any flexibility at all, the cheaper side of the anniversary is usually the right side, which is a conversation worth having with the programme manager before the go live date is fixed rather than after. And the anniversary itself: if yours sits on your busiest month, that is a renewal ask, it costs nothing to request, and it removes a structural disadvantage that otherwise repeats every single year for as long as you hold the agreement. The note is important, so let me say it directly: none of this is avoidance. Every genuine user is reported. It is scheduling the same reality so that a temporary population does not become a permanent commitment.
Last check. A six hundred person acquisition closes six weeks before your anniversary. Integration will take a year, and the acquired company has its own Microsoft agreement running for another eight months. What is the counting question? A, add all six hundred to this year's true up immediately. B, establish first whether those users are qualified under your enrollment yet: entity scope decides that, and while they remain covered by their own agreement they may sit outside your profile, so the sequencing of the integration is also a commercial decision. C, leave them out permanently since they have their own licences. Or D, report them next year regardless of the facts. Pause here. Which document decides whether those six hundred people are inside your enrollment?
The answer is B, and the first move is factual rather than arithmetical. Your enrollment's entity scope and profile decide who is qualified, so the questions are: has the acquired entity actually been brought inside the enrollment, and are those users currently licensed under your agreement or still under their own? While their agreement runs, paying twice for the same six hundred people is a genuine risk, and so is under reporting if the entity has in fact been added, which is why the answer is establish, then report. Now the commercial insight inside B, which is the part worth keeping: integration timing is often flexible by weeks or months, and a true up creates a permanent floor, so the sequencing decision carries a three year price and deserves to be made with that visible rather than as a purely technical migration plan. A reports before establishing the facts and risks double payment. C makes a permanent assumption out of a temporary state, since their agreement ends in eight months and those users have to land somewhere. D defers a question that has a correct and available answer today. Module eight covers corporate events properly, including what transfers and what does not.
The operating rhythm, three habits that convert the true up from an annual event into a routine. The ninety day calendar: diarised, owned, repeating, extraction at ninety, HR reconciliation at sixty, reclamation at forty five, count at twenty one, submission at seven, and understand that missing that window costs you a year, every year, because the floor you set is permanent. The working papers: the basis of the count, the exclusions and the reason for each, the reclamation log, filed annually so that next year begins from evidence rather than from memory, and so the count survives a question asked long after the people involved have moved on. And the renewal feed, which is the habit that pays twice: every anniversary produces exactly the data your renewal will need, the growth trend, the reclamation yield, the distance to the next price band from session six. The true up file becomes the renewal file, and module six spends five sessions showing you what a good one is worth. Next session takes the metrics themselves: per user, per device, per core, subscription against perpetual, and the interactions between them that produce the surprise findings.
Session seven, three sentences. One: the annual order bills your additions at contracted rates, which makes growth genuinely cheap inside an EA, and the number you report becomes a floor with no downward step for the remainder of the term. Two: the admin centre counts objects and the enrollment counts a defined population, so the reconciliation between those two, run across ninety days rather than a fortnight, is what turns a submission into a decision, and Tom's client measured that difference at two hundred and forty committed accounts. Three: scheduling belongs to you, seasonal peaks, project onboarding, and the anniversary date itself all change what a true up costs, and none of it is avoidance, it is the same reality timed deliberately. Next week, the metrics. See you there.
Homework, about an hour, and the first item alone is worth the session. One, diarise the five dates: your anniversary minus ninety, sixty, forty five, twenty one, and seven, each with a named owner, because that single calendar entry changes what next year's count costs. Two, run the delta: assigned licences today against what you reported at the last anniversary, and split the difference into the four populations, new hires, leavers, duplicates, service accounts. Three, price the artefacts: multiply the non hire populations by your contracted rate and by the remaining years of your term, because that number, with a currency symbol on it, is the business case for the calendar and it is the version your CFO will actually read. Four, settle the profile questions: for service and test identities, does your enrollment's definition make them qualified users, answered once in writing rather than argued annually. And five, look at the timing: any seasonal peak or major onboarding within two months of your anniversary, and if there is one, that is a scheduling conversation worth having now, while the dates are still movable.
Five reads before next session, all free on redress compliance dot com. First, the EA true up guide, which carries the counting mechanics and the calendar in reference depth and is the natural companion to today. Second, Microsoft licensing true ups and how to avoid costly mistakes, a catalogue of the specific errors that turn one anniversary into a permanent cost, including the two Tom described. Third, the true up process guide, step by step, including who does what and when, which is useful if you are handing this to someone else to run. Fourth, the Microsoft licence reclamation guide, for the reclamation pass in practice with the populations to look for and the tooling to find them. And fifth, the usage review template, which is a ready made internal review you can run before the count rather than inventing your own. That is session seven. The count is yours, the floor is permanent, and ninety days turns a submission into a decision. Next week, the metrics. See you there.