How to Reconcile Multi-Site IT Asset Registers with DeepSeek

The short answer: Export each site's asset spreadsheet alongside your Intune or AD device list, describe the columns and the matching rules to DeepSeek in plain language, and have it normalise serial-number formats, match records across sources, and flag every disagreement. You get a defensible one-off reconciliation in a day. You do not get anything that stops the registers diverging again.

Ask an IT manager with sites in Shenzhen, Suzhou and Hong Kong how many laptops the company owns, and you will get a number. Ask where the number comes from, and you will get three spreadsheets in three different shapes, an Intune export, and a fixed-asset register from finance that agrees with none of them.

Nobody is lying. Each source was built for a different purpose, maintained by a different person, and last updated at a different time. The site lists exist so a local admin can find a machine. The Intune export exists so devices get patched. Finance's register exists so assets get depreciated. They were never designed to reconcile, and until someone asks for a company-wide number, nothing forces them to.

Matching messy records across inconsistent sources is a task language models are genuinely good at — not because it is hard, but because it is the kind of easy that a person cannot do ten thousand times without making mistakes. DeepSeek suits this job because the source data is usually half in Chinese: site spreadsheets with 型号 and 使用人 columns sitting next to English serial numbers, mixed date formats, and location names written three ways. A model that reads both languages natively removes a translation step, and every step you remove is a class of error you no longer introduce.

Why Nobody Knows How Many Laptops the Company Owns

Four reasons, and they compound.

Each site keeps its own list, in its own shape. One tracks by serial number, one by asset tag, one by the user's name. Columns differ, headers are in different languages, and at least one list has a merged cell holding two machines on one row.

The lists are maintained by exception. Records get added at purchase and updated when something goes wrong. Nothing updates them when a laptop is quietly handed to a new joiner, carried to another site, or left in a drawer after somebody resigns.

Nobody owns the total. Each site owner is accountable for their own list; nobody is accountable for the sum. A number no single person is measured on is a number that drifts.

The systems that would fix this were bought for something else. Intune and Active Directory know about devices that check in — excluding anything switched off, re-imaged, in a store cupboard, or never enrolled. Finance's register knows what was purchased and never learns what happened after. Both are accurate within their scope and silent outside it.

The consequence is not philosophical: over-buying because nobody trusts the spare count, licences paid on machines retired two years ago, and an audit question that takes three weeks to answer badly.

Getting the Source Data Into a Shape a Model Can Reconcile

The preparation is most of the work, and it is not technical.

Which three sources actually disagree?

Start by naming exactly what you are comparing, because "we have a few spreadsheets" is not a scope.

The site spreadsheets are ground truth for who physically has what, and unreliable for everything else. They carry assigned user and location correctly, because that is what the local admin needs, and carry purchase dates and model names badly.

The Intune, Jamf or AD export is ground truth for what is actually running and checking in — authoritative on serial number, OS build and last-seen date, and blind to any device never enrolled.

Finance's fixed-asset register is ground truth for what was bought and what it is worth on the books. It is authoritative on purchase date and cost, often records twenty laptops as one line, and rarely carries serials at all.

State this out loud before you start, because it determines which source wins when two of them disagree — and that rule, not the model, is what makes the output defensible.

What matching rules do you have to state explicitly?

A model will infer rules if you do not give it any, and inferred rules are where silent errors come from. Write them down and put them in the prompt.

Serial-number normalisation. Strip spaces and hyphens, decide whether case matters, and say what to do with values Excel prefixed with an apostrophe or truncated in a narrow column. Dell service tags, Lenovo serials and Apple serials have different shapes; say which you expect.

Field mapping across languages. Tell it that 序列号 and "Serial No." are the same column, that 使用人 maps to assigned user, and that 已报废 in a status column means retired. This is where a bilingual model earns its place — you are describing a mapping rather than translating a file and hoping nothing shifts.

What counts as a match. Exact serial match is a match. Same asset tag with different serials is a conflict, not a match. Same user and same model with no serial on either side is a *candidate*, and candidates must be flagged for a human, never merged automatically.

What to do with the leftovers. Every record that matched nothing is a finding with a type: in Intune but on no site list, on a site list but never seen by Intune, on finance's books but nowhere else. Ask for them separated — each type has a different follow-up.

Keep the data proportionate. A hardware reconciliation needs no home addresses, phone numbers or HR identifiers, and fewer personal fields means a smaller governance question later.

A Practical Reconciliation Pass — Normalise, Match, Flag, Then Verify by Hand

Work in four passes rather than asking one question and hoping.

Pass one — normalise, and only normalise. One file at a time, output a clean single-schema table: serial, asset tag, model, assigned user, site, status, purchase date, source. No matching yet. Review one site's output against the original before going further; if the normalisation is wrong, everything downstream inherits it.

Pass two — match on the strong key. Ask for exact serial matches across the normalised sets, plus matched and unmatched counts per source. Numbers that do not add up are your first real finding, and usually point at a normalisation problem rather than a genuine gap.

Pass three — propose the weak matches. Now ask for candidates on the softer signals, each with a stated reason: "same asset tag and same assigned user, serial missing from the site list." Insist on the reason. A candidate list without reasoning is unreviewable; with reasoning it takes about a minute per row.

Pass four — classify the exceptions. Group the unmatched records by exception type, each with a suggested next action: physically locate, confirm retired, chase the site owner, correct the finance register.

Then verify by hand — and sample the *matches*, not just the exceptions. Exceptions get scrutiny automatically because they look wrong; confident-looking incorrect matches are the ones that get accepted. Twenty matched rows checked at random against the source files is twenty minutes that tells you whether the run is trustworthy.

On a first pass across four sites, expect most records to reconcile cleanly, a meaningful minority to land in the candidate pile, and a stubborn remainder to be genuinely missing devices — that last group no amount of data work resolves. Somebody has to walk into a room and look.

A One-Off AI Reconciliation vs a Real Asset Management System

• Time to a trustworthy number — AI reconciliation wins outright. A day of work against a project that needs a system, a rollout and a process.
• Cost to start — AI reconciliation wins. It is an API bill and your own time, with nothing to procure.
• Handling messy, bilingual, inconsistent input — AI reconciliation wins, and it is not close. This is exactly the shape of problem a system with strict schemas handles worst.
• Preventing the same drift next quarter — A managed asset register wins, decisively. A reconciliation is a photograph; a register with a check-out/check-in workflow and an Intune sync is a process that stays current.
• Audit and compliance evidence — The register wins. "Here is our asset system, with assignment history and depreciation schedules" answers an auditor; "here is a spreadsheet we cleaned up with AI in March" invites a follow-up question.
• Licence and warranty control — The register wins. Seat tracking and expiry alerts are continuous jobs, not one-off analyses.

The honest read: use the AI pass to size the problem and produce a clean baseline, then put that baseline somewhere that maintains itself. The first without the second means doing the first again next year.

The Part That Decides Whether It Was Worth It

Who owns the register afterwards.

A reconciliation produces a clean list on a specific date. From that moment it decays at roughly the rate your organisation moves hardware — which in a multi-site China operation with contractors, transfers and normal staff turnover is faster than most people estimate. Six months later you have three spreadsheets again, plus a fourth: the reconciled one, now also wrong.

The clean list is only worth the effort if two things happen. Somebody is named as the owner of the total, not just of their own site. And every event that moves a device — issue, transfer, return, retirement — writes to one place as it happens, rather than being reconstructed later from memory.

That is the whole argument for a system rather than an exercise. Brocent's FINOS IT Asset Manager exists for this shape of problem: auto-numbered asset records carrying serial, asset tag, assigned user, location, status and warranty dates; check-out and check-in so assignment history is captured as it happens; Microsoft Intune sync so enrolled devices flow in rather than being retyped; licence seat tracking with expiry warnings; and depreciation schedules that give finance the view they kept their own list for. It comes with Brocent Managed IT rather than as a separate subscription, which removes the usual reason these projects stall.

Getting This Right — Asset Data, Cross-Border Transfer, and When to Bring in IT

Three practical points before you upload anything.

Treat the export as personal information, because it is. A hardware register with an assigned-user column is personal information under China's PIPL — the device is identified, but so is the person holding it. The mitigation is proportionality rather than paperwork: strip or pseudonymise the user column before the file leaves your environment, reconcile on serial and asset tag, and re-attach names locally afterwards. Most reconciliation logic never needed the names.

Understand where the processing happens. Sending a site register to any hosted model is a data transfer, and if the file leaves mainland China it may be a cross-border one with its own requirements. DeepSeek publishes open-weight models that can be run on infrastructure you control, which is the cleanest answer when a file cannot leave your environment — and if you use the hosted API instead, check the current terms for the tier you are actually on rather than assuming, since tiers differ and terms change.

Know which half of the problem you are solving. The analysis is the cheap half. Physically locating the devices that matched nothing, deciding what is genuinely lost, correcting finance's register, and then keeping the result accurate is the work — and it is what our AI+ support practice and managed IT support are built to carry. Brocent has run managed IT across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016; multi-site China estates where every location keeps its own list are ordinary territory for us. The same data-residency reasoning applies to any internal AI workload — we covered it in more depth for China-compliant internal knowledge assistants.

Frequently Asked Questions

Does serial-number and user data count as personal information under PIPL?

The assigned-user column does, and that is usually enough to bring the whole file into scope. A serial number alone is device data; a serial number next to an employee's name identifies a person. The practical answer is to drop the name column before export and reconcile on serial and asset tag, which most of the matching logic uses anyway. Where names must stay, keep the file in your own environment and use a self-hosted model.

How accurate is AI fuzzy matching on asset serial numbers?

Exact matching after normalisation is highly reliable because it is deterministic — the value is in the normalisation, not the matching. Fuzzy matching on partial serials, model names and user names is useful but should never be trusted silently: require a stated reason for every candidate and have a person confirm each one. Treat it as a shortlist, not a result.

What do we do with assets that appear in only one list?

Classify them by which list they appear in, because each type means something different. In Intune but on no site register means the register is incomplete. On a site register but never seen by Intune means unenrolled, retired, or gone. On finance's books only usually means it was disposed of without anyone telling finance. The first two are data fixes; the third is a write-off conversation.

How often should this be redone?

From spreadsheets, quarterly is realistic and annually is too slow to be useful. But frequency is the wrong thing to optimise: a reconciliation you have to repeat is a symptom. Once movements are captured in one system as they happen, the exercise becomes a spot check rather than a project.

Can we do this without sending data to a hosted AI service?

Yes. DeepSeek releases open-weight models that run on your own hardware or a cloud instance you control, and reconciliation is a good fit — batch work, not latency-sensitive, no need for the largest model. This is the standard answer where contracts, regulators or internal policy prohibit sending asset data outside.

Does this replace an asset management system?

No, and treating it as a replacement is the main way this goes wrong. It replaces the *manual cleanup* an asset system would otherwise need before you could load it — real value, because that cleanup is usually what stalls the project. The output is a clean baseline; the system keeps the baseline true.

Where to Start

Pick the two sites whose numbers disagree most, export their registers and the matching Intune slice, and run the four passes on that subset alone. Two hours tells you the two things worth knowing before committing to anything bigger: how far apart your sources actually are, and whether the gap is a data problem or a physical one. If the data cleans up fine but nobody can say who owns the total, that is the conversation worth having — get in touch.