MB-800: Business Central Configuration That Holds Up in Daily Operations

MB-800, Microsoft Dynamics 365 Business Central Functional Consultant, validates the ability to configure a business application for companies that need dependable financial, purchasing, sales, inventory, and reporting processes. Microsoft's current English skills outline was updated June 30, 2026. It covers Business Central setup, financials, sales and purchasing, and daily operations. The exam is active as of the October 10 checkpoint. A successful functional consultant needs to understand why a configuration works in a real organization, not merely how to complete the setup wizard.

Business Central often serves small and midsize businesses whose employees handle multiple responsibilities. The same person might create a purchase order, process inventory, issue an invoice, and reconcile a bank account. That makes sensible automation and permissions especially important. A system that requires dozens of unnecessary steps can slow the business, while one that allows uncontrolled changes may jeopardize financial accuracy. Good setup achieves a practical balance between ease of use and reliable records.

Configure companies, users, and basic application behavior

Company setup begins with legal and accounting identity, base currency, fiscal calendars, address and tax information, and the flow of operational documents. A consultant should map the business structure before importing data. One organization may require several distinct companies because of legal separation; another may need departments or locations within the same company. The choice affects intercompany processes, reporting, inventory visibility, and permissions.

Data migration is not finished when records are imported without an error message. Customers, vendors, items, opening balances, and outstanding documents must be reconciled against authoritative sources. Test reference relationships and document status before releasing the environment for business use. A vendor number imported with the wrong payment terms may create errors long after the migration job has reported success. Assign business owners to sign off the converted data.

Role centers, profiles, personalized views, and permission sets should fit how users work. A purchasing employee may need supplier commitments and outstanding receipts on one screen, while a finance manager needs overdue reconciliations and approvals. Excessive role customizations increase maintenance, but ignoring genuinely different responsibilities makes errors more likely. Design and test with representative users rather than using administrator accounts that can perform every action.

Number series, job queues, report layouts, and standard workflows affect the reliability of routine operations. Numbering may carry legal or auditing consequences, especially for posted documents. Job queues should have monitoring and restart procedures; an overnight process can fail without someone noticing until the next reporting cycle. Workflow approvals need escalation rules, delegation, and a record of who approved what. Features such as built-in Copilot assistance should be enabled with a clear understanding of data access, accuracy expectations, and support responsibilities.

Design the chart of accounts and posting groups carefully

A chart of accounts should reflect the financial statements and management needs of the company. Too many accounts make processing and reconciliation difficult; too few obscure economically different activity. Financial dimensions enable analysis by department, product line, project, or location without creating a separate general-ledger account for every combination. Establish rules for default and prohibited dimension values, and test documents that move across departments or reporting periods.

Posting groups connect operational events to accounts. General business and product posting groups, VAT or tax setups, customer and vendor posting groups, and inventory posting groups may all influence a document's financial result. Incorrect setup can post revenue or expenses to the wrong account while a sales or purchase transaction appears successful. Trace a sales invoice and a purchase receipt through to their general-ledger entries; verify the groups involved at each transition.

Currencies and exchange rates introduce additional complexity. A company purchasing in one currency and reporting in another needs controlled rate sources and agreed revaluation treatment. Do not confuse currency conversion at document posting with period-end adjustment of monetary balances. Configure payment terms, payment methods, and cash discounts based on policy, then test rounding, partial settlement, and credit-note behavior.

Fixed assets extend beyond purchasing an item. Acquisition, capitalization, depreciation books, disposal, and transfers need consistent posting rules. A laptop recorded as an expense in one organization may qualify as a fixed asset under another's capitalization policy. Configure for the actual accounting treatment and test the full life cycle, including transfer between departments and correction of an incorrect acquisition value.

Run purchasing and sales as connected processes

Purchasing begins with a need and ends when the organization has accepted goods or services and correctly records the liability. Vendor cards, item prices, purchase quotes, orders, receipts, invoices, and returns form a connected sequence. An item delivered in the wrong quantity may require a partial receipt; a defective shipment may require a return rather than an inventory adjustment. Use realistic cases to confirm which documents users should create and when stock is considered available.

The sales cycle has its own sequence: customer setup, pricing, quotation, order, shipment, invoice, payment, and possible return. A customer-specific discount may interact with a campaign or quantity price. Test how price calculations behave with mixed currencies, partial shipment, and backorder. An invoice should represent what has actually been supplied under the agreed contract, not merely what someone originally ordered.

Inventory availability and location management depend on timely postings. Recording a shipment after a truck has departed can make available stock appear higher than it is. Recording a receipt before acceptance can conceal a quality problem. Define who owns each operational step and what evidence is needed before posting. A small company may have simple locations; a more complex business might require bins and directed warehouse operations. Choose a level of configuration that reflects actual activity.

Approvals should be meaningful and proportionate. Requiring managerial review for every small purchase can delay operations, but allowing unrestricted changes to vendor banking information is risky. Combine workflow conditions, role separation, and review of unusual activity. The general control reasoning in Dynamics 365 finance processes is related, although Business Central has its own setup and operational semantics.

Maintain journals, bank reconciliation, and daily controls

General journals and recurring journals support transactions that do not originate in standard sales or purchasing workflows. Establish batch naming, balancing rules, reason codes where appropriate, and approval requirements. A recurring journal can save work but also replicate an outdated amount month after month. Review recurring postings regularly and ensure that the control owner knows how to correct and reverse an error without hiding the audit trail.

Bank reconciliation compares Business Central entries with the bank's evidence. The difficult cases involve timing differences, fees, partial settlements, duplicate payments, or payments with unclear references. Define when a mismatch can be investigated and when a write-off or adjustment requires authorization. Testing a perfect one-to-one reconciliation is useful initially but insufficient for a production-ready process.

Accounts receivable and payable need aging reviews and exception handling. A customer's unpaid balance could result from a true dispute, a missing remittance reference, or an incorrect document. An overdue payable may be waiting for goods acceptance rather than approval. Reconciliation routines should expose these causes; a total that balances only after unexplained manual journals is not a trustworthy result.

Inventory journals require similar discipline. Adjustment and reclassification should be backed by a physical or business event: counting discrepancy, damage, transfer, or correction of master data. Track what changed, who approved it, and whether follow-up process improvement is required. Frequent adjustments for the same item or location indicate a root-cause problem, not merely a need for faster posting.

Make reports, dimensions, and workflows explain decisions

Operational reports should help users answer clear questions: which receivables need attention, what stock is committed, which purchases have not been received, and where actual expense deviates from budget. Choose appropriate filters and dimension values, and confirm the report agrees with posted documents. A visually impressive dashboard that silently excludes one company or unusual dimension creates false confidence.

Role-center cues and charts can surface exceptions, but their definitions require review. A cue showing “late shipments” must identify which promised date is used and whether partial shipment counts as late. The same principle applies to overdue payments and unapproved invoices. Explain the calculation to business users and provide drill-through to the supporting records so decisions can be audited.

Business Central can integrate with Microsoft 365 and Power Platform capabilities. Choose automation based on the operational reason for it. A notification may be sufficient for an approval task; a data transformation may require a supported integration. Identify the authoritative source and failure behavior before synchronizing records. Don't create a separate editable copy of every customer or item attribute without resolving which system may change it.

Validate the implementation with transaction stories

A strong MB-800 study exercise configures a company with a realistic chart of accounts, dimensions, customers, vendors, and stocked items. Create a purchase order, receive fewer units than ordered, record the invoice, then sell and ship part of the accepted inventory. Trace the general-ledger entries, customer and vendor balances, on-hand inventory, and bank settlement. This tests whether operational decisions produce correct financial evidence.

Add a return, a credit memo, a foreign-currency invoice, and an approval exception. Have a user with restricted permissions carry out the process, and verify that they cannot override sensitive controls. Test whether report layouts, automated jobs, and approval notifications continue to work after a supported application update. When a defect appears, identify whether it is configuration, incorrect source data, misunderstanding of business policy, or missing functionality.

The separate MB-820 developer examination addresses AL extensions, integration, and technical lifecycle management. A functional consultant should know when a requirement can be met through standard Business Central setup and when a supported extension is justified, but should not substitute custom code for a well-understood business process. The lasting skill behind MB-800 is the ability to connect company setup, financial posting, purchasing, selling, inventory, and daily controls into a system business users can trust.