Audit

MS Access database expert · schema, SQL & data model · remote USA, UK, Canada

Hire an MS Access Database Expert When the Problem Is the Data Model, Not the Code

If your Access reports produce different totals depending on which form you run them from, the problem isn't the report. If your queries need DISTINCT to avoid duplicate rows, the problem isn't the query. If your VBA has forty lines of transformation code before it can display a number, the problem isn't the VBA. These are data model problems — and fixing them at the root costs less and stays fixed longer than writing more code to work around them.

  • Reports don't reconcile with the accounting system — the gap is consistent and nobody can explain it.
  • DISTINCT in every query that aggregates money — someone added it to suppress duplicates that the data model should prevent.
  • The same customer entered six different ways — search is broken and revenue reports double-count.
  • Cascade deletes that nobody planned removed records — now there are orphan rows and totals that don't foot.
  • VBA compensating for the database: transformation code, re-aggregation before display, manual de-dup routines in form load events.

I specialize in the category of Access problems that other developers call 'weird' — the ones where the database technically runs but produces results nobody trusts. That's almost always a schema or query grain problem, and fixing it is what I do.

  • Senior MS Access database expert
  • USA · UK · Canada — remote
  • Direct work, no relay chain
Hire MS Access ExpertReview My Schema

Same-business-day triage when you send your Access and Office version, bitness, and time zone.

All scoped work runs on copies first — no debugging on live production data.

Describe the problem

Tell me the specific mismatch: which report is wrong, what it shows vs. what it should show, and your Access and Office version. If you have query names, include them. Sanitized copy welcome — I work on copies, never on live production.

Max 15MB. Access, PDF, Excel, ZIP, or images—if it helps explain the issue.

See Our Work — Real MS Access Dashboards We've Built

Every dashboard is custom-built to match your business workflow

Job tracking and inventory valuation MS Access dashboard samples
Customer management and sales summary MS Access dashboard samples
Inventory, purchase order, timecard, and payroll MS Access dashboard samples
Get Your Custom Dashboard

The Access Problems That Actually Need a Database Expert — Not Just a Developer

  • Report totals that don't match the general ledger — consistent gap, consistent direction, nobody can trace it through the query stack.
  • Duplicate records that keep coming back after manual cleanup — because the data model has no enforcement preventing new ones from being created.
  • Linked SQL Server tables with no meaningful keys on the Access side — join behavior that works in small tests and explodes under real data volume.
  • Lookup fields used as structural relationships — UI shortcut that breaks exports, upsizing, and any query that needs to join on the value.
  • Split FE/BE architecture where critical lookup tables are still local to one machine — 'it worked fine until Sarah was out sick.'
  • Cascade deletes with no audit trail — deleted records, orphaned foreign keys, totals that changed without explanation.
  • Historical imports that created duplicate customer or vendor records — no matching rules defined at import time, no deduplication since.

What an MS Access Database Expert Actually Does

  • Schema analysis: full ERD pass — tables, primary keys, foreign keys, relationships, cardinality, and the redundancy that's causing your query output to be wrong.
  • Query grain audit: trace the top five reports with wrong totals back through the query stack to the join or grouping that's inflating or deflating the number.
  • Normalization on hot paths: restructure the tables that are causing the most downstream pain — staged so existing forms and reports keep working during the fix.
  • Index strategy for your actual Jet/ACE workload: not textbook recommendations, but indexes on the real join columns and filter fields your queries use.
  • Duplicate prevention: primary key enforcement, unique indexes on the fields that identify a record, and import validation to stop new duplicates at the entry point.
  • Upsizing readiness assessment: data types, reserved words, relationships, and pass-through query design — what's actually required and what it won't fix.
  • FE/BE boundary review: what belongs in Access, what should move server-side, and what the current split architecture is getting wrong.

Why Microsoft Access Specifically Rewards — and Punishes — Expert-Level Database Knowledge

Access is unusually permissive. It lets you bind UI directly to tables, skip primary keys, use Lookup fields as relationships, and build a multi-user database on a single .accdb file with no enforced concurrency controls. This permissiveness is why Access is approachable for non-developers — and why Access databases built without expert oversight accumulate structural debt that compounds over time.

The Jet/ACE query optimizer behaves differently from SQL Server in ways that catch developers who move between platforms. A query that runs acceptably in SQL Server can perform orders of magnitude worse in Access because the optimizer can't use an index on an expression, or because the join order isn't what you'd expect, or because a subquery that's fine in T-SQL translates to a full table scan in Jet. An Access database expert knows these specific failure patterns and writes SQL accordingly.

The other Access-specific trap is the Lookup field. Access encourages storing relationships via Lookup field properties in the table designer — a UI convenience that hides the actual stored value from queries and exports, causes problems when the lookup source changes, and makes it nearly impossible to upsize cleanly to SQL Server. I see this in almost every database that was built without specialist oversight, and it's one of the first things I address in a schema review.

Who Needs to Hire an MS Access Database Expert

Finance and accounting managers

Running month-end close on an Access database where the reports don't tie to the GL. They've been manually reconciling the difference for months. They need an expert who will trace the mismatch through the query stack and fix it at the source — not patch the report.

Operations directors inheriting a broken database

Took over responsibility for an Access database built by someone who left. The database runs, but nobody trusts the output. Reports produce different numbers depending on how you run them. The expert who built it is gone and the documentation is thin.

IT managers evaluating SQL Server migration

Considering migrating Access to SQL Server because something is slow or broken. They need an expert to tell them honestly whether migration will fix the actual problem — or whether the problem will migrate with the data because it lives in the query design, not the storage layer.

Business owners with duplicate data problems

Running an Access database where the same customer, vendor, or product appears in multiple records. Every report that aggregates by entity is wrong. Manual cleanup keeps getting undone because nothing prevents new duplicates from being created.

Developers who know Access but hit the expert ceiling

Comfortable building forms and writing VBA, but stuck on a data model problem that's outside their experience. They need a specialist who can diagnose and fix the structural issue without rewriting the whole application.

Companies preparing for an audit

Access database is part of the financial reporting chain and an audit is coming. They need someone who can verify that the query logic matches the stated business rules — and document what the database actually does vs. what it's supposed to do.

Hire an MS Access Database Expert Before the Next Report Audit Fails

Limited expert slots open this month. The fastest path to a scope: send the mismatch — the report name, what it shows, what it should show, and your Access version. If you have query names, include those too.

No intake form. No sales call. You hire an MS Access database expert and get the person who reads your schema, traces the problem, and fixes it — same thread, start to finish.

Hire MS Access ExpertReview My Schema

What the Database Looks Like After an Expert Has Worked on It

  • Report totals that reconcile to the GL — because the query grain matches the business event and the joins are correct.
  • Fewer defensive patterns in VBA — less transformation code, fewer workarounds for things the database layer should be handling itself.
  • Duplicate records blocked at the source — unique indexes and import validation, not manual Friday-afternoon cleanup.
  • A documented schema — table purposes, key definitions, relationship logic, and query intent written down so the next person who opens the file isn't starting from zero.
  • A clear picture of what SQL Server upsizing would actually require — and whether it would solve the problems you're actually experiencing.

How a Database Expert Engagement Starts

  • You send the symptom — the specific report that's wrong, the query that produces bad results, the gap between Access and the GL. The more specific, the faster the triage.
  • I do an ERD pass on a sanitized copy: tables, keys, relationships, obvious structural issues, and the queries that feed the reports you care about most.
  • You get a written findings summary: what's causing the problem, what a fix requires, what the risk is if we change it, and what's out of scope.
  • Change plan with risk ranked — what breaks if we fix keys first, what can be done without touching existing forms, what requires a coordinated deployment.
  • Fixes ship in documented blocks. You know what changed, why, and how to verify it. Every structural change includes rollback notes.

Case Study (Short)

The situation

A US manufacturing company running order and invoice reporting through Access. Every month-end, the Access revenue total was 8–12% higher than the accounting system. A previous developer had added DISTINCT to the main revenue query to suppress what they thought were duplicate rows — which masked the problem but didn't fix it. Finance had been manually adjusting the Access number for over a year. Nobody could explain the gap, and the assumption was that "Access just isn't accurate."

What actually happened

The order table and the invoice table had a one-to-many relationship that wasn't reflected in the Access relationship diagram. The main revenue query joined them without a proper relationship definition, creating row multiplication — every order was appearing once per invoice line against it. DISTINCT suppressed some duplicates but not all, and the suppression wasn't consistent across order types. Fixed the join condition and added the missing relationship. Revenue query now produces the same number as the accounting system to the cent. DISTINCT removed. No more monthly manual adjustment.

MS Access Database Expert vs. General Access Developer

Problem typeDatabase expert approachGeneral developer approach
Report total doesn't match GLTraces join grain through query stack, fixes at sourceRewrites report query; may not find root cause
Duplicate recordsAdds unique constraints, fixes import validationRuns deduplication script; duplicates return
DISTINCT used to suppress bad totalsRemoves DISTINCT, fixes the join causing the duplicatesLeaves DISTINCT, adds more workarounds
Slow queries on large tablesAnalyzes actual query plan, indexes join/filter columnsAdds indexes to all columns or rewrites in VBA
SQL Server migration evaluationHonest assessment of what migration solves vs. doesn'tMay recommend migration without assessing whether it fixes the problem
VBA with heavy data transformationFixes the database layer so VBA doesn't need to compensateOptimizes the VBA code
Schema documentationDocuments table purposes, keys, and query intentVaries — often not included

Hire an MS Access Database Expert — USA, UK & Canada

Remote MS Access database expert services delivered across three countries.

When you hire an MS Access database expert for the USA, UK, or Canada, you get the same senior-led work: keys and relationships that reflect how your business actually operates, SQL with correct grain, and a clear change plan before anything structural gets touched. I work with teams in the cities below — and beyond this list when time zones and secure file transfer line up.

USA

New YorkLos AngelesChicagoHoustonPhoenixPhiladelphiaSan AntonioSan Diego

UK

LondonManchesterBirminghamLeedsGlasgowLiverpoolNewcastleSheffieldBristolEdinburghCardiffBelfastNottinghamSouthamptonBrighton

Canada

TorontoMontrealVancouverCalgaryEdmontonOttawaWinnipegQuebec CityHamiltonHalifaxVictoriaSaskatoonReginaKitchenerMississauga

United States, United Kingdom, and Canada—cities and regions above are examples of where clients hire me; remote delivery works the same elsewhere when hours overlap.

Don't see your city listed?

I work remotely across the USA, UK, and Canada. When you hire an MS Access database expert through this site, you get me on the thread — not a relay desk.
Hire MS Access ExpertReview My Schema

Related: MS Access database consulting services, MS Access database solutions, Hire MS Access developer.

Related pages

What clients say

Operations and finance leads—real engagements, not placeholder quotes.

Olivia R.

Operations Manager, Logistics Firm (USA)

“Five stars—our MS Access database developer rebuilt reporting so leadership trusts the numbers. Weekly reporting dropped by more than half with zero manual merges.”

Callum P.

Director, Manufacturing SME (UK)

“Outstanding Access database services: they repaired corruption, fixed slow queries, and documented everything. Our team finally has a stable system we can grow with.”

Amelia D.

Finance Lead, Distribution Company (Canada)

“Professional, fast, and clear. As an MS Access consultant they nailed scope, hit milestones, and cut finance support tickets dramatically—highly recommend.”

Frequently asked questions

Straight answers about hiring an MS Access database expert — what the work involves, what problems it solves, and what to expect.

What does an MS Access database expert actually do that a regular developer doesn't?
A regular Access developer can build forms and write VBA. An MS Access database expert understands why your data model is producing wrong results — and fixes it at the root instead of writing more code to compensate. The difference shows up most clearly when reports don't reconcile: a developer rewrites the report, an expert fixes the query grain and the table relationships that caused the mismatch. It also shows up in multi-user performance, in migration readiness, and in any situation where the problem isn't 'the button doesn't work' but 'the system produces numbers nobody trusts.' That last category is almost always a data model problem, not a VBA problem.
How do I know if my Access database has a data model problem vs. a code problem?
A few reliable signals: your reports produce different totals depending on which query or form you run them from. DISTINCT appears in queries that shouldn't need it — someone added it to suppress duplicates that the data model should be preventing. VBA has large blocks of code that transform or re-aggregate data before displaying it — signs that the database layer isn't producing clean output on its own. Form validation is duplicated across multiple forms because there's no enforcement at the table level. And the most telling one: when you export to Excel and manually reconcile, you get a different number than what Access shows. That gap is almost never an Excel problem.
My Access database reports don't match our accounting system. Can you fix that?
Yes — and this is one of the most common high-priority problems I'm brought in to solve. The mismatch is almost always a query grain problem: the Access query is joining tables in a way that creates implicit row multiplication, or it's grouping at the wrong level, or it's including records that shouldn't be in scope. I trace the discrepancy from the report back through the query stack to the table relationships, identify exactly where the numbers diverge, and fix the SQL at the source. I also document what caused it so you can verify the fix and explain it to your accounting team.
What does 'query grain' mean and why does it keep breaking Access reports?
Grain is the unit of measurement that one row in a query or table represents. If your sales table has one row per line item and your customer table has one row per customer, joining them correctly means one output row per line item — the grain of the sales table. If the join is set up wrong, or if there's a missing relationship that forces Access to create a Cartesian product, you get multiple output rows per line item and your totals are inflated. This is the most common reason Access reports produce numbers that are too high. The fix is correcting the join condition and often restructuring the query to match the grain of the business event you're actually measuring.
Can you fix an Access database that has duplicate records everywhere?
Yes. Duplicate records in Access almost always trace to one of three causes: no primary key enforcement (or a primary key that's defined but not meaningful), no unique constraint on the fields that actually identify a record, or an import routine that ran without a deduplication check. The fix has two parts: a one-time cleanup pass to identify and merge or remove the duplicates, and structural changes to prevent new ones from being created — primary key enforcement, unique indexes on the right fields, and import validation logic. I scope both parts separately so you know exactly what each involves before committing.
Will you rebuild my entire database or can you fix just what's broken?
Most of the time, targeted fixes are the right approach — and I'll tell you honestly when that's the case. A full rebuild is warranted when the data model is so structurally compromised that fixing it piecemeal would cost more than starting clean. That's a specific finding I document with evidence, not a default recommendation. For most databases I work on, the right path is: fix the keys and relationships that are causing the most pain, rewrite the specific queries that are producing wrong results, and make the VBA less defensive because the database layer is now enforcing what it should have been enforcing all along.
Can you work on an Access database that's linked to SQL Server?
Yes — this is a common setup and one I work in regularly. Access as a front end linked to SQL Server tables has its own specific issues: join behavior between linked tables and local queries, pass-through query design for operations that should stay on the server, connection string management and linked table refresh reliability, and transaction handling across the boundary. The expertise required is different from pure Access-only work, and I bring both sides of it.
Is my Access database ready to migrate to SQL Server, and can you tell me honestly?
I can assess it and tell you what's actually driving the question. Most Access-to-SQL-Server migration conversations start because something is slow or something broke — and in many cases the right answer is 'fix the Access database first, then reassess.' SQL Server upsizing solves specific problems: concurrent write volume above what Jet/ACE handles well, data volume beyond Access file size limits, enterprise security requirements. It doesn't solve query grain problems, bad data models, or poorly written VBA — those problems migrate with the data. If migration is genuinely warranted, I'll tell you what it requires and what it won't fix.
How do you handle sensitive data during a database review?
I work on sanitized or anonymized copies whenever possible — production data never needs to be on my machine for diagnostic work. For cases where real data is required to reproduce a specific issue, I operate under NDA, use secure file transfer, and delete copies after the engagement closes. I don't use test data in production environments and I don't leave copies of your database on any shared or cloud-synced storage.
What should I send to get started with an MS Access database expert?
Four things get us moving fast: your Access and Office version plus bitness (32 or 64-bit), a description of the specific problem — the report that doesn't reconcile, the query that produces wrong totals, the performance issue on a specific form, a sanitized copy of the database or at minimum a schema export, and what 'fixed' looks like in concrete terms — what number should the report produce, what should the query return. The more specific the symptom, the faster the triage. If you don't have a sanitized copy ready, tell me what the data sensitivity situation is and we'll figure out the right approach.
How long does it take to fix a data model or schema problem in Access?
It depends on the scope and how deeply the bad design is embedded in the existing queries and forms. A targeted fix — correcting keys, fixing one join grain problem, rewriting three to five queries — typically takes a few days to a week of focused work. A broader schema review with staged normalization across multiple tables takes two to four weeks depending on how many downstream objects reference the tables being changed. I scope each engagement individually and give you a realistic estimate before work starts. I don't quote flat rates for problems I haven't seen.
Hire Now