Main modules

Vendor groups

Where: Accounts payable > Setup > Vendor groups. Vendor groups are the bridge between vendors and posting profiles. Each group represents a set of vendors that share posting behavior, terms of payment, and reporting buckets. Common groupings: domestic vendors, foreign vendors, intercompany, employee-expense vendors, capital-expenditure vendors. The vendor group also drives the Settle period and Posting profile defaults.

Vendor posting profiles

Where: Accounts payable > Setup > Vendor posting profiles. Posting profiles map AP transactions to GL accounts. Three account-code priority levels: Table (specific vendor), Group (vendor group), All (everyone). Most companies design at the Group level. Key accounts:

• Summary account: the AP control account on the balance sheet. Marked as "Do not allow manual entry" so it can only move via the subledger.
• Settle account: liquidity ledger account, used by cash-flow forecast (only when cash flow forecasting is enabled).
• Arrival / Offset: for the Invoice register journal flow, where invoices are recorded before approval and posted to a temporary Arrival account, later transferred to the Summary on approval.
• Sales tax prepayments: for prepayment scenarios where tax is recoverable in advance.

Methods of payment

Where: Accounts payable > Payment setup > Methods of payment. Defines how cash leaves (check, electronic, wire, promissory note). Per method:

• Account type: Bank, Vendor, Ledger.
• Payment status flow: None / Sent / Approved / Rejected; controls reconciliation back to bank statement.
• File format: the Electronic Reporting (ER) format used for export, control report, return, and remittance, e.g., NACHA (US ACH), ISO20022 pain.001 (used by SEPA and most modern bank standards), country-specific ER configurations.
• Bridging account: intermediate account used between payment release and bank clearing.
• Payment specification: ACH transaction codes (CCD, CTX, PPD).
• Period: per-invoice or total-vendor settlement.

Terms of payment, payment days & cash discounts

Where: Accounts payable > Payment setup > Terms of payment / Payment days / Cash discounts. Terms calculation methods: Net (X days from invoice), Current month (X days from end of month), COD, Specific date. Payment days mapping bumps the due date to the next configured payment day (e.g., always Friday). Cash discounts (2/10 net 30); F&O auto-stacks the next discount when the earlier tier expires. Payment schedules support installment payment with allocation method = total / fixed amount / percentage.

Charges codes & auto charges

Where: Accounts payable uses the Procurement-side Charges code (Procurement and sourcing > Setup > Charges > Charges code). On vendor invoice posting, charges from the PO carry through; standalone vendor invoices (without a PO) can have charges added directly. Tolerance for charge variance vs. PO is set on AP parameters; significant variances flag for review.

AP parameters

Where: Accounts payable > Setup > Accounts payable parameters. Drives defaults: invoice approval workflow, three-way matching policy (No / Two-way / Three-way), tolerance percentages for matching, the default posting profile for prepayment journal vouchers, and number sequences.

The vendor master is the single source of truth for everyone you pay. Get it right at setup and downstream AP, procurement, and reporting all behave; get it wrong and you'll be cleaning up posting errors and duplicate payments for months.

Vendor creation, step by step

Where: Accounts payable > Vendors > All vendors > New.

Required fields

• Vendor account: usually pulled from a number sequence; only manual if you've set it that way.
• Name: picks from or creates a Global Address Book party. Same legal entity name should never be a separate party.
• Group: drives posting profile, terms of payment, and tax defaults. The most consequential field on the form.
• Currency: invoice currency. Can differ from accounting currency; FX revaluation handles the rest.

Tabs to fill before going live

• Addresses: at least one purpose=Invoice address. Without it, payment formats with address blocks fail silently.
• Contact information: remit-to email for ACH advice, AP contact phone.
• Purchase order defaults: delivery terms (Incoterms), mode of delivery.
• Invoice and delivery: invoice account (third-party pay-to vendor if different), tax group, item sales tax group.
• Payment: terms of payment, method of payment, cash discount, payment specification (such as ACH/CCD/CTX), bank account.
• 1099: only for US AP. 1099 box (NEC, MISC, INT, DIV) and 1099 status. Wrong here = wrong year-end form.

Common pitfalls

• Duplicate vendors. AP won't enforce uniqueness on Tax ID by default, turn on the "vendor search" warning in AP parameters and train AP clerks to search before creating.
• Wrong group at creation. Group can be changed later, but historical postings already used the old posting profile, so reporting splits across two summary accounts.
• Hold field forgotten. Hold = Payment is a safe default during onboarding (lets you receive invoices but blocks payment until verified).
• One-time vendors abused. One-time vendor is for genuinely one-shot payments, not a shortcut, you lose reporting history.

Vendor bank accounts

Where: on the vendor record, Vendor > Setup > Bank accounts. Capture either IBAN/SWIFT (international) or routing/account (US ACH). Mark one bank as the default so it flows to the payment proposal automatically. Vendor bank account approval workflow (in AP parameters) gives auditable control over who can change a vendor's bank, the change vector with the highest fraud risk in AP.

Vendor on-hold options

The Hold field on the vendor record blocks specific transaction types: No (no block), Invoice (blocks invoice posting), Payment (blocks payment posting), All (blocks both invoice and payment), Requisition (blocks new POs and requisitions), Never (excluded from auto-hold via inactivation). Typical onboarding flow: Hold = All on creation, AP supervisor verifies bank and tax info, then sets Hold = No.

Vendor onboarding via Vendor Collaboration

Prospective-vendor self-service is supported via the Vendor Collaboration portal: an external user signs up via Azure AD B2B, completes a registration wizard with company details and certifications, and triggers a New Vendor Request in F&O. Procurement reviews and approves; on approval the vendor is created with the right group and posting profile. The flow is configured under Procurement and sourcing > Setup > Vendor collaboration and requires Public Sector or Vendor Collaboration license.

Three invoice paths

• Vendor invoice (PO-matched): Accounts payable > Invoices > Pending vendor invoices. Invoice header tied to the PO; matched against PO line and product receipt before posting. Three-way match enforces price (PO vs invoice) and quantity (receipt vs invoice) tolerances configured in AP parameters and per matching policy. Invoice match status is shown on the invoice header. Invoice can also be generated on the PO level.
• Invoice journal: Accounts payable > Invoices > Invoice journal. Direct journal entry without a PO, used for non-PO invoices like utilities or rent. Distribution lines pick up the expense account and dimensions.
• Invoice register / Invoice approval journal: two-step entry where the Invoice register posts to an Arrival account on receipt, and the Approval journal moves it to the vendor liability after review. Used in environments with separation of duties between AP clerk and approver.

Vendor Invoice Automation (VIA) and electronic invoicing

Microsoft now offers Vendor Invoice Automation that uses AI to extract header and line data from PDF invoices, plus the Electronic invoicing service for country-specific e-invoice schemas (Italy SDI, France Chorus Pro, Mexico CFDI, Saudi ZATCA). Both reduce manual entry and improve compliance.

Prepayments

Two flows: Prepayment invoice (a real AP invoice posted to a prepaid asset, with VAT recoverable per local rules, applied later against a standard invoice on the same PO) and Prepayment journal voucher (cash advance recorded directly without an invoice, ideal where local tax law does not allow VAT recovery on advances). Prepayment policy is configured per PO in the Prepayments tab.

Payment journal

Where: Accounts payable > Payments > Payment journal. Manual creation of payment lines per vendor / invoice. Method of payment drives the file format and the offset bank account. Approval workflow can be added on the payment journal name.

Payment proposal

Inside the payment journal, Functions > Payment proposal auto-generates lines for vendor invoices that match selection criteria (due date, vendor group, currency, method of payment). The most efficient way to run a weekly check run.

Settlement

Settlement matches a payment to one or more invoices. Auto-settlement is enabled per posting profile via the Settlement option. Manual settlement uses Vendor > Settle > Settle open transactions. Cash discounts taken at payment post automatically if the discount window covers the payment date.

PDC (Post-Dated Cheques)

Common in Middle East and parts of Asia: a check dated in the future is recorded as PDC, settling at maturity. F&O supports this via the PDC functionality on the payment journal where the check is registered as PDC at issuance, then realized on the maturity date. Configured under AP parameters > Updates > Use post-dated checks.

Foreign currency revaluation

Where: Accounts payable > Periodic tasks > Foreign currency revaluation. Revalues open AP balances in non-functional currencies at month-end. Posts unrealized FX gain/loss against the AP account; reverses next period (depending on policy). Typical close-step ordering: AP > AR > Bank > GL.

1099 (US year-end)

Where: Accounts payable > Periodic tasks > 1099. Generates 1099-NEC, 1099-MISC, 1099-INT, 1099-DIV forms based on vendor 1099 box assignments and posted invoices. Run year-end after all December activity is final. Verify amounts before generating; corrections post-generation are painful.

AP close checklist

• All vendor invoices entered and approved.
• Three-way match exceptions resolved (no orphaned product receipts).
• Period-end accruals booked for receipts not invoiced.
• Payment proposal run, payments posted, settlement complete.
• FX revaluation posted.
• AP aging tied to GL trial balance.
• AP period status closed in General ledger > Periods > Ledger calendars.

• Vendor aging (Accounts payable > Inquiries and reports > Vendor aging report): buckets by aging period (custom-defined per company). Reconciles to AP control account.
• Vendor balance list: by vendor as of a date. Quick reconciliation tool.
• Vendor account statement: all transactions for a vendor in a period (open and closed).
• Vendor transactions: the operational inquiry an AP clerk lives in; filterable by status, due date, etc.
• Power BI / Financial Reporter: for executive AP dashboards (DPO, top vendors, % auto-matched invoices).

Customer groups

Where: Accounts receivable > Setup > Customer groups. Customer groups bridge customers and posting profiles. Common groupings: domestic, foreign, intercompany, retail, wholesale, government. Group also drives default terms of payment, posting profile, and tax parameters.

Customer posting profiles

Where: Accounts receivable > Setup > Customer posting profiles. Same Table / Group / All priority logic as AP. Key accounts:

• Summary account: AR control account on the balance sheet (asset side). "Do not allow manual entry" by default.
• Settle account: liquidity ledger account for cash flow forecasting (when enabled).
• Liability account for deposits: for customer prepayments / advance receipts before invoicing.
• Sales tax prepayments: for customer prepayment invoices with tax.

Methods of payment

Where: Accounts receivable > Payments setup > Methods of payment. Defines how cash arrives (electronic deposit, check, credit card, lockbox). Per method:

• Account type: Bank, Customer, Ledger, Vendor.
• Payment status flow: None / Sent / Received / Approved / Rejected (drives reconciliation).
• File format: the Electronic Reporting (ER) format used for export, control report, and return; different formats per region (lockbox BAI2, NACHA return file, ISO20022 pain.001).
• Bridging account: intermediate account used between deposit and bank clearing.
• Period: per-invoice settlement vs. total customer balance.

Terms of payment, payment days & cash discounts

Where: Accounts receivable > Payments setup > Terms of payment / Payment days / Cash discounts. Terms calculation methods: Net (X days from invoice), Current month (X days from end of month), COD (cash on delivery), Specific date. Payment days refine due date by mapping to a specific weekday or day-of-month (e.g., always due on the 25th). Cash discounts incentivize early payment with a tiered discount (2/10 net 30); F&O auto-stacks the next discount when an earlier tier expires. Payment schedules support installments with allocation method = total / fixed amount / percentage.

Charges codes & auto charges (sales side)

Where: Accounts receivable > Charges setup > Charges code and Auto charges. Mirror of the procurement-side mechanism. Customer charges (freight, handling, restocking, fuel surcharge) are added to a sales order at the header or per line, automatically via auto-charge rules keyed on Account code (Table / Group / All) and Item code. Debit type on the charge code determines posting: Customer (charge to customer's invoice), Ledger (post offset to internal account). On invoice posting, the charge appears as a separate line on the customer invoice.

AR parameters

Where: Accounts receivable > Setup > Accounts receivable parameters. Drives defaults: invoice creation behavior, free-text invoice settings, customer write-off setup (account and limit), default posting profile for prepayment journal vouchers, dunning configuration, and number sequences. (Credit management options moved to the dedicated Credit Management module since 2019; see the Credit & Collections module.)

Customer creation

Where: Accounts receivable > Customers > All customers > New.

Required fields

• Customer account: from a number sequence; manual only if configured that way.
• Type: Organization or Person (drives address book behavior and tax handling).
• Customer group: drives posting profile, terms, defaults.
• Currency: invoice currency. Different from accounting currency triggers FX revaluation.

Tabs to fill before going live

• Addresses: Invoice address (purpose=Invoice), Delivery address (purpose=Delivery), and any custom address purposes the company uses.
• Contact information: primary contact, AR contact, billing email for electronic invoice delivery.
• Sales demographics: sales group, segment, salesperson commission setup, sales tax exempt number.
• Invoice and delivery: delivery terms (Incoterms), mode of delivery, sales tax group, item sales tax group.
• Payment defaults: terms of payment, method of payment, cash discount, payment specification.
• Credit: credit limit, credit hold rules, credit rating (with Credit Management module), exception flags.

Customer addresses and one-time customers

Customers can have multiple addresses with different purposes (invoice, delivery, business, payment). The default Invoice address is what shows on the printed invoice. For genuinely one-shot transactions, use one-time customer (set up as a template under AR parameters), the customer record is created on the fly from a sales order without persisting in the master.

Customer hold and exclusion

The Hold field on the customer blocks transactions: All, Invoice, Payment, Requisition, No, Never. The Hold value flows down to sales orders. For temporary credit blocks driven by limits, use Credit Management (covered in the Credit and Collections module) instead of manual Hold.

Sales-order invoice

Generated from a posted sales order. Driven by Sales and Marketing operationally; the AR posting profile determines the GL accounts hit (AR, revenue, sales tax, COGS, inventory). Most B2B invoicing follows this path.

Free-text invoice

Where: Accounts receivable > Invoices > All free text invoices. A direct AR invoice without a sales order, used for non-inventory billing (services, rent, fees, miscellaneous charges). Lines reference main accounts and dimensions directly, not items. Recurring free-text invoices are configurable for subscription-style billing without the full Subscription Billing module.

Customer payment journal

Where: Accounts receivable > Payments > Customer payment journal. Records customer payments, manual or imported. Settlement against open invoices is selected via the Settle transactions function. Auto-settlement is configured per posting profile.

Credit memos and write-offs

Credit memos are negative invoices that reverse revenue / AR (with an optional return-of-goods leg via the Return order if inventory is involved). Write-offs are configured under AR parameters with an account and an approval threshold; clear uncollectible balances to bad-debt expense or against an Allowance for Doubtful Accounts reserve.

Customer statements

Generated periodically, list all transactions on a customer's account for a period or as of a date. Used for customer reconciliation; not the same as a dunning letter.

Dunning / collection letters

Where: Credit and collections > Setup > Collections > Collection letter. Dunning rules send progressively firmer reminders to customers as invoices age. F&O has migrated most collections functionality to the dedicated Credit and Collections module, but dunning configuration still includes letter templates, fee posting, and exclusion rules.

Foreign currency revaluation

Where: Accounts receivable > Periodic tasks > Foreign currency revaluation. Revalues open AR balances at period-end. Posts unrealized FX gain/loss; reverses or persists per policy.

AR close checklist

• All sales orders and free-text invoices posted.
• Customer payments applied (no aged unapplied receipts).
• Credit memos and write-offs reviewed and posted.
• FX revaluation posted.
• AR aging tied to GL trial balance.
• AR period closed.

• Customer aging (Accounts receivable > Inquiries and reports > Customer aging report): aging buckets per defined periods; reconciles to AR control account.
• Customer balance list: snapshot of open balance per customer.
• Customer account statement: all transactions in a period, sent to the customer for verification.
• Days Sales Outstanding (DSO): derived metric from AR aging and revenue, the leading indicator of collection efficiency.
• Power BI / Financial Reporter: for AR dashboards, top customers by AR, aging trend, collection effectiveness.

Asset Management parameters

Where: Asset management > Setup > Asset management parameters. Default work order types, journal names, posting profiles, and toggles for Fixed Assets integration. The integration toggle controls whether maintenance costs above a threshold can be capitalized to the underlying fixed asset.

Lifecycle states

Where: Asset management > Setup > Asset and functional location > Lifecycle states. State machine for assets and work orders (Created > Active > Under maintenance > Decommissioned > Scrapped). Custom states allowed; transitions are governed by lifecycle models.

Work order types and job types

Work order types describe the work category (Preventive, Corrective, Inspection, Project). Job types describe specific tasks (Lubrication, Belt replacement). Both feed into work order line creation.

Reason codes

Per work order type: failure reason, downtime reason, asset history reasons. Drives root-cause reporting.

Where: Asset management > Common > Assets > All assets and Asset management > Common > Functional locations > All functional locations.

Functional locations

Hierarchical taxonomy of where assets sit (Plant > Building > Production line > Machine). Critical for spatial / process-step reporting.

Assets

Each maintained piece of equipment is an Asset. Assets can be linked to a functional location, a parent asset (for sub-assemblies), and to a Fixed Asset record (for accounting). Asset attributes capture make, model, serial, install date, warranty.

Asset BOMs

List of replaceable components on an asset (motor, belt, bearing). Drives spare-parts planning and maintenance task templates.

Counters and meters

For usage-based maintenance: hours run, miles driven, cycles. Counter readings trigger condition-based maintenance plans.

Where: Asset management > Common > Work orders > All work orders.

Work order lifecycle

Created > Scheduled > In Progress > Reported as Finished > Ended. Each transition triggers state-machine actions: scheduling, resource booking, cost capture, asset history update.

Work order job journals

Three journal types per work order:

• Hour journal: labor time captured against the work order.
• Item journal: spare parts consumed (from inventory).
• Expense journal: external services or fees.

Journals post to the GL via Asset Management posting profile and to the asset history for future reporting.

Scheduling

Schedule board (similar to Field Service) shows worker availability and work-order assignments. Drag-drop assignment, capacity warnings, skill-matching.

Maintenance plans

Where: Asset management > Setup > Preventive maintenance > Maintenance plans. Time-based (every 90 days) or counter-based (every 1,000 hours) recurring work-order generation.

Maintenance rounds

Group of inspection / minor maintenance tasks performed in sequence (a daily walkdown of a production line). Generates one work order with multiple lines per round.

Condition assessments

Capture asset condition data (vibration reading, oil temperature) on a schedule; trigger maintenance when readings exceed thresholds. Foundation for IoT-based predictive maintenance integrations.

IoT integration

Microsoft has progressively added connectors for IoT data feeds (Azure IoT Hub, Connected Field Service patterns) that surface alerts and auto-create work orders. Implementation depends on the IoT solution chosen and is integration-grade work.

• Inventory Management: spare parts consumed via item journals; reservations supported per work order.
• Procurement and Sourcing: spare parts purchased via PO directly to a work order; turnkey services purchased and matched to work order lines.
• Fixed Assets: when activated, maintenance costs above the capitalization threshold can be transferred to the linked Fixed Asset record (component replacement, major overhaul). Most maintenance is expensed; capital improvements are not.
• Production Control: resources used for both production and maintenance (a CNC operator who also does basic maintenance) require capacity coordination.
• Project Management and Accounting: long-running maintenance projects (annual shutdowns) often run as projects with Asset Management work orders inside.

Budget parameters

Where: Budgeting > Setup > Budgeting parameters. Drives default journals, default budget code, number sequences, and the toggle for using budget plans / budget control.

Budget codes

Where: Budgeting > Setup > Budget codes. Each code represents a type of budget entry (Original, Revision, Transfer, Encumbrance, Pre-encumbrance, Carry-forward). Pre-encumbrance and Encumbrance are public-sector / government features; commercial enterprises use Original / Revision / Transfer.

Budget cycles

Defined as time spans (typically 12 monthly periods making up a fiscal year). Budget plan and register-entry cycles align to fiscal calendar, so set the calendar correctly first.

Dimensions in budgets

Budgets carry the same financial dimensions as actual postings, allowing apples-to-apples comparison. Decide which dimensions are mandatory in budgets at design time, more dimensions = more granular control but more planner effort.

Where: Budgeting > Budget register entries. Direct entry of budget figures per main account, dimensions, period, currency, and budget code. The simplest pattern: an annual planning exercise produces a list of budgeted amounts per account / cost center, loaded as register entries via Excel.

Budget register entries flow to the budget data store and are visible in financial reporting (Trial balance with budget column, Financial Reporter budget statements) and in the Budget vs. actuals reports.

Use this approach when planning happens outside F&O (in Excel, Anaplan, etc.) and the goal is just to hold the numbers in F&O for reporting. No workflow, no scenarios, no real planning UI.

Budget planning process

Where: Budgeting > Setup > Budget planning > Budget planning processes. Defines the lifecycle: stages (Draft, Manager Review, Director Review, Finalized), scenarios (Original budget, Revised forecast, What-if), allowed templates, and the workflow that moves a plan from stage to stage.

Budget plan templates

Excel-based templates linked to F&O via dual-direction integration. Planners do work in Excel (familiar interface, formulas, copy/paste from prior year) and publish back to F&O. Each plan is dimensioned per the planning process configuration.

Allocation

Budget plan allocation rules redistribute totals across periods or dimensions: monthly distribution from an annual figure, allocation across cost centers based on a basis. Reduces line-by-line entry effort.

Generate budget register entries from plan

Once a budget plan is finalized, generate budget register entries from it to push the figures into the ledger budget store. The link from plan to register entries preserves the audit trail.

What budget control does

When enabled, F&O checks the available budget at the moment a document is created (PO, requisition, expense report, journal) and either warns or blocks if the document would exceed the budget. The toughest control level in budgeting.

Configuration

Where: Budgeting > Setup > Budget control > Budget control configuration. Activate the source documents to check (PR, PO, journal, expense), the dimensions to check at, the over-budget threshold (warn at 90%, block at 100%), and the user permissions for override.

Available budget calculation

Available = Budget revisions, Actual expense, Encumbered (open POs), Pre-encumbered (requisitions). Each is configurable in the Budget funds available calculation.

Over-budget vs. warn-vs-block

Operational flexibility: most commercial implementations warn at 100% and block at 110%, allowing minor over-runs but stopping major violations. Pure-block configurations frustrate operations and lead to workarounds.

• Trial balance with budget column: built-in comparison view in GL.
• Financial Reporter: ships standard budget statements (income statement with actual / budget / variance columns), customizable by row / column / tree definitions.
• Budget control statistics: shows pre-encumbered, encumbered, actuals per dimension combination.
• Budget plan reports: exports of any plan stage to Excel for executive review.
• Power BI: for advanced budget-vs-actual dashboards, consolidations across legal entities, scenario modeling.

• Over-engineered budget control: blocking POs at $5 over a $50,000 budget breaks operations. Tune thresholds and use warnings before hard blocks.
• Dimension overload in plans: 8-dimension budget plans take 10x longer to maintain than 3-dimension plans, with little reporting benefit.
• Year-end roll-forward forgotten: next-year budget must be loaded before Jan 1, or the new year shows 100% over-budget on day one.
• Plan vs. register-entry confusion: a plan that isn't finalized and pushed to register entries is invisible to financial reports.
• Forecast updates without scenario tracking: use Scenarios in Budget plans to track Original vs. Revised vs. Latest Estimate; don't overwrite the Original.

Bank groups

Where: Cash and bank management > Setup > Bank groups. Group bank accounts (typically by bank institution: Bank A, Bank B). Holds default routing / SWIFT / address values for the institution, inherited by every bank account in the group.

Bank accounts

Where: Cash and bank management > Bank accounts > Bank accounts. Each bank account is tied to:

• Main account: the GL account that this bank reflects (the cash account on the balance sheet).
• Currency: bank account currency. Multi-currency requires advanced bank reconciliation.
• Bank statement format: the import format used (BAI2, MT940, ISO20022 camt.053).
• Reconciliation type: Standard (legacy), Advanced (recommended).
• Bank account number / IBAN / SWIFT: identifiers for electronic payment files.

Bank transaction types

Where: Cash and bank management > Setup > Bank transaction types. Classifies each ledger journal line that hits a bank account: deposit, fee, interest earned, NSF return, transfer in, transfer out, wire fee, etc. Each transaction type maps to a default offset main account, so when a user records a bank fee they pick the type and F&O posts the correct GL contra. Required setup before Advanced bank reconciliation can match statement lines automatically.

Bank transaction groups

Where: Cash and bank management > Setup > Bank transaction groups. Aggregate bank transaction types for reporting (e.g., "Bank fees" group includes wire fee, ACH fee, monthly maintenance) and for advanced bank reconciliation matching rules. Match rules can target a transaction group rather than every individual type, reducing rule volume.

Cash and bank parameters

Where: Cash and bank management > Setup > Cash and bank management parameters. Drives default behavior: check number sequence, deposit slip ID, FX revaluation defaults, advanced bank reconciliation defaults, bank document management toggle.

Bank account approvals

Critical control: bank account changes (especially vendor / customer bank accounts) carry fraud risk. Approval workflow on bank account changes is a recommended best practice and a common audit finding when missing.

Check layouts

Where: on the bank account, Bank account > Check > Layout. Defines the physical check format: prenumbered or computer-numbered, position of payee, amount, signature. Layouts now use the SSRS / Electronic Reporting framework.

Electronic Reporting (ER) for payment formats

F&O ships dozens of country-specific payment formats as ER configurations: NACHA (US ACH), SEPA Credit Transfer (EU), ISO20022 pain.001 (international XML), MT103 (SWIFT wire), BACS (UK). Each is configurable to add custom fields, change layouts, or branch behavior per bank requirement. Microsoft's Globalization Studio is replacing the older ER editor for new configurations.

Bank statement formats

Inbound: BAI2 (US bank standard), MT940 (SWIFT), camt.053 (ISO20022). Each format maps to a standard ER configuration; customize for bank-specific quirks.

Bank document management (newer feature)

Microsoft's Bank Document Management module automates the connection to bank portals (via Microsoft-managed connectors), removing manual statement import. Available for select banks; verify per region.

Deposit slips

Where: Cash and bank management > Bank statements > Deposit slip. Group customer payments into a single deposit slip that matches what hits the bank in one batch. Reconciliation matches the slip total to the bank deposit, individual payments inside the slip stay grouped.

Check operations

From the bank account: void check, refund check, stop payment, NSF processing. Each generates the appropriate reversal journal in AP and the bank account.

Bank-to-bank transfers

Where: Cash and bank management > Periodic tasks > Bank account transfer. Move cash between own bank accounts. Posts to a clearing / transit account if accounts are in different currencies.

PDC (Post-Dated Cheques)

Where used (Middle East, parts of Asia), PDCs are tracked in F&O against the bank account. Issuance posts a PDC liability; maturity processes the actual cash movement; rejection or cancellation reverses cleanly.

Manual (Standard) reconciliation

Where: on the bank account, Reconcile > Account reconciliation. Tick off ledger entries that match the bank statement. Acceptable for very low volume; otherwise unworkable.

Advanced bank reconciliation

The recommended pattern. Import the bank statement (BAI2, MT940, camt.053), match rules auto-pair statement lines to ledger transactions, exceptions go to a worksheet for manual handling. Match rules are configurable per bank account: by amount, by reference, by date range, etc.

Reconciliation accounting

When enabled, advanced bank reconciliation can auto-post journals for items that exist on the statement but not the ledger: bank fees, interest, NSF returns. Reduces month-end manual journal effort substantially.

Best practice

Reconcile weekly, not monthly. Aged unreconciled items become difficult to investigate after 30 days. Bank clearing / suspense accounts must reconcile to zero at every period end.

Cash flow forecast configuration

Where: Cash and bank management > Setup > Cash flow forecasting setup. Activate the cash flow forecast on each main account (with Type = Liquidity for bank, AR, AP control accounts). For ledger accounts, set the cash flow time fence (when the activity becomes a forecasted cash event).

Source data

• AP open invoices and POs, scheduled by due date.
• AR open invoices and sales orders, scheduled by due date.
• Budget figures, scheduled by period.
• Manual cash flow entries for known but uncommitted events.

Forecast generation

Where: Cash and bank management > Periodic tasks > Cash flow forecasts > Calculate cash flow forecasts. Schedules a batch run; results visible in the Cash overview workspace and exportable to Power BI.

Predictive cash flow (newer feature)

Microsoft has added AI-driven predictive cash flow features that forecast customer payment timing using historical payment behavior (under Finance Insights / agents). Improves forecast accuracy versus pure due-date logic.

Cost accounting ledger

Where: Cost accounting > Setup > Cost accounting ledger. Ledger holds: cost element dimensions, cost object dimensions, statistical dimensions, fiscal calendar, currency, the version structure (actual / budget / forecast).

Dimension hierarchies

• Cost elements: the "what" (what kind of cost). Map from GL accounts.
• Cost objects: the "where" (department, cost center, product line). Map from GL financial dimensions.
• Statistical dimensions: the "how to allocate" (headcount, square footage, machine hours, units produced). Map from external sources.

Versions

Actual, budget, forecast can each be a version. Comparison reports cross versions (actual vs. budget contribution margin).

Cost control unit

The combination of dimensions used for allocation and reporting in a particular run. Multiple cost control units allow different views (manufacturing vs. service business) of the same source data.

GL as source

Cost transactions imported from GL via integration job (typically monthly). Maps GL account > cost element, GL dimensions > cost objects.

Statistical providers

Statistical measures (headcount per department, square footage per facility) imported from HR, fixed assets, or external Excel / DMF. Frequency: usually monthly or quarterly.

Budget integration

Budget Control budgets feed budget version of cost accounting. Allows variance analysis at cost-object level.

Refresh cadence

Typical pattern: monthly refresh after GL close. Cost accounting is point-in-time view; running it more often is possible but adds processing overhead.

Allocation policies

Define how indirect costs flow from one cost object to others. Driven by formula or hierarchy.

Formula allocation

"Allocate facility cost to departments based on square footage." Source = facility cost; basis = square footage statistical; targets = departments. Engine computes per-target share and posts allocation lines.

Hierarchy allocation

Multi-step: corporate > division > department. Each level applies its own driver (e.g., division allocates by revenue, department by headcount). Run order matters; the engine respects the configured sequence.

Overhead calculation

Apply standard overhead rates to direct costs (typical for product costing rolling up overhead at cost-object level for product cost).

Calculation run

Submit a calculation job: imports source data, runs allocations in order, posts to cost accounting ledger. Audit trail shows each allocation step. Reversible by deleting the run.

Cost control workspace

Cost-object owner's view: actual vs. budget by cost element, drill-down into transactions / allocations. Designed for managers who own a cost center.

Contribution margin analysis

Revenue minus direct cost minus allocated overhead per product / customer / segment. Reveals true profitability after support costs distributed.

Power BI integration

Cost accounting data exposed via entity store; Power BI dashboards for executive contribution-margin analysis, allocation transparency, what-if scenarios.

Statement

Cost accounting "statement" report: source data > allocations applied > final cost-object totals. The audit document for managerial reporting.

Justified when

• Allocation logic has 3+ steps, with statistical drivers that don't exist as GL postings.
• Multiple managerial views needed (legal entity vs. product line vs. customer segment).
• Mature finance team has a Director of FP&A or similar role to own the model.
• Existing GL allocation rules / Subledger Accounting can't express the policy cleanly.

Overkill when

• Single dimension allocation (department X gets 10% of corporate; can be done in GL).
• Mid-market client without dedicated managerial reporting function.
• Reporting needs can be met by Power BI on top of GL data.

Implementation pitfalls

• Source-mapping drift: GL accounts created later not mapped to cost elements; data leaks.
• Statistical refresh discipline: drivers stale, allocations skewed.
• Reconciliation neglected: cost accounting actuals diverge from GL; trust erodes.
• Over-engineered: 5-level hierarchies that nobody can explain to a department manager.

Costing methods

• Standard cost: fixed unit cost; differences from actual become variances. Best for stable-price, repetitive manufacturing.
• FIFO: first-in, first-out, oldest cost flows to COGS first.
• LIFO: last-in, first-out (allowed under US GAAP, prohibited under IFRS).
• Weighted average: period-end average cost across all transactions.
• Moving average: recalculated unit cost on every receipt; no inventory close required.

Item model groups

Where: Inventory management > Setup > Inventory > Item model groups. The most consequential setup in F&O Cost Management. Drives:

• Inventory model (FIFO, LIFO, weighted avg, moving avg, standard).
• Whether to post physical inventory (at receipt / packing slip) and financial inventory (at invoice).
• Whether to allow negative inventory.
• Whether to register costs at PO confirmation, packing slip, or invoice.

Cost groups

Categorize cost contributions: material, labor, overhead, sub-contract. Used by the costing sheet to split unit cost into reportable buckets.

Costing sheet

Where: Cost management > Indirect cost component setup > Costing sheet. Defines how unit cost is built up: direct material + direct labor + manufacturing overhead (often as % of labor or per-unit rate). Drives the cost build-up shown on a finished good and the variance accounts hit.

Cost versions

Where: Cost management > Predetermined costs > Cost versions. Hold the standard cost for items as of an effective date. Two states:

• Planned: being prepared for the next standard cost roll, can be modified.
• Active: the live standard cost; only one version per item is active at a time.

BOM calculation

For manufactured items, the BOM calculation walks the BOM hierarchy and sums material costs + route operations × labor / overhead rates to produce the finished-good standard cost. Run before activating a new cost version.

Cost rolls

Annual or semi-annual standard cost roll: prepare planned cost version, BOM-calculate, review, activate. The activation creates a revaluation journal that adjusts inventory value to the new standard.

Inventory recalculation

Where: Cost management > Periodic tasks > Inventory recalculation. Reapplies the costing model and adjusts existing transactions for any cost changes (received cost, settle issues to receipts). Reversible until the period is closed.

Inventory close

Where: Cost management > Periodic tasks > Inventory close. Final cost calculation for the period; settles all issues to specific receipts per costing model (FIFO / LIFO / weighted average). After close, the cost is locked for the period; only future-dated transactions can be adjusted.

Frozen periods

An inventory close locks the period; no posting allowed back-dated into it. Critical for audit integrity but can frustrate operations if the close is too eager. Coordinate with operations on close date.

Subledger accounting (newer)

F&O has progressively migrated cost accounting events to the Subledger Accounting framework, which gives finer-grained control over which accounts receive which cost transactions. Adoption depends on F&O version.

Under standard costing, every difference between actual cost and standard becomes a recognized variance:

• Purchase price variance (PPV): invoice price differs from PO standard.
• Cost change variance: standard cost was changed mid-period; existing inventory revalued.
• Lot size variance: for production, the standard fixed cost per setup is over-/under-absorbed when lot size differs.
• Quantity variance (production): actual material consumed differs from BOM.
• Substitution variance: different material used than BOM specified.
• Resource variance: actual labor / machine hours differ from route.

Each variance posts to a separate GL account if configured (and almost always should be). Variances on the P&L tell finance where standards are stale and where execution differs from plan.

• Inventory value report: per item / warehouse / dimension, must reconcile to inventory control account.
• WIP report: open production order WIP balance, reconciles to WIP control account.
• COGS reconciliation: COGS GL = sum of inventory issues at cost. Mismatch = manual journal hit COGS or wrong item model group.
• Standard cost variance reports: by variance type, by period, by item.
• Inventory aging: stock by age bucket; supports obsolescence reserve calculation.
• Cost Management workspace: consolidated view of variances, WIP, valuation.

Credit management parameters

Where: Credit management > Setup > Credit management parameters. Default credit limit, currency, blocking rules at sales order / picking / packing slip / invoicing, escalation thresholds.

Credit groups

Group customers (by industry, region, risk class) for shared credit policy. Per-group default limits, terms, blocking rules.

Credit limit type

• None: no check (used for prepay-only customers).
• Balance: check against open AR balance only.
• Balance + delivery + delivery note: include shipped-not-invoiced exposure.
• Balance + all: include open sales orders not yet shipped (fullest exposure view).

Risk score & rating

Customer risk score: configurable formula combining payment history, days-late metrics, external scores (e.g., D&B import). Drives credit limit suggestions and rule weighting. Risk rating: discrete tier (A, B, C) overlaid on score.

Blocking rules

Per rule: applies-to (customer subset), trigger (over limit, expired credit, on hold), action (block, warn, escalate). Rules evaluated at sales-order events and produce credit blocks.

Credit management workspace

Where: Credit management > Workspaces > Credit management. Credit analysts see blocked orders, customers near limit, expired credit insurance, and risk-score changes. The daily cockpit for credit teams.

Credit hold types

• System-driven: auto-applied when limit exceeded or rule triggers.
• Manual: credit team applies for due-diligence reasons.
• Customer-level: entire customer on hold (all orders).
• Order-level: specific order blocked, others flow.

Release workflow

Configurable approval workflow for credit hold release. Typical: credit analyst proposes > CFO / VP Sales approves > release applied. Audit trail captures justification.

Temporary limit increase

Time-bound credit limit override (effective from / to dates). Used for one-time large orders without permanently raising the limit.

Order block at picking

Common scenario: order entered when customer was within limit, but by picking time another order or invoice pushed them over. Block fires at picking; warehouse gets a clean stop, credit team negotiates.

Collections parameters

Where: Credit and collections > Setup > Collections parameters. Currency rounding, default reason codes, automatic case creation rules, write-off thresholds.

Collections agents

Workers tagged as collections agents, each owning one or more customer pools. Pool definitions are query-based (customer group, industry, region, balance threshold). Assignment is many-to-many capable.

Aging period definitions

Bucket definitions (e.g., Current, 1-30, 31-60, 61-90, 91+). Multiple aging-period definitions allow management view, audit view, and customer-statement view.

Activities

Phone call, email, letter, customer-visit log entries against a customer or invoice. Each activity stamped with date, agent, outcome, follow-up. The audit trail of collection effort.

Cases

For complex disputes (price discrepancy, delivery short, billing argument), a case structure tracks the issue separately from the underlying invoice and ties to the resolution.

Aging snapshots

Periodic process: Credit and collections > Periodic > Aging snapshot. Captures point-in-time aging per customer per pool; agents work from the snapshot. Snapshots avoid the moving target of live aging.

Collections list

Worklist generated from snapshot; sorted by amount, age, customer. Agents work through, log activities, take actions (call, send letter, dispute, write off).

Collection letters (dunning)

Multi-stage letter sequence per terms-of-payment: courtesy reminder > first letter > final demand. Configurable text, format (e-mail or print). Triggered automatically based on age or manually per customer.

Interest notes

Charge interest on overdue invoices per terms / interest code. Posted as separate invoice or accrued. Some industries / regions auto-apply, others negotiate per customer.

Customer payment proposals (when paying)

The opposite end: when customer pays, payment-journal proposals match cash to invoices. Auto-matching uses remittance advice fields (invoice number on lockbox file).

Write-off journal

Where: from the customer or invoice, Collect > Write off. Posts a credit note clearing the invoice, with the offset to bad debt expense (or a reserve account). Configurable: full write-off, partial, with sales-tax recovery handling per region.

NSF (returned check) processing

Customer payment bounced. F&O reverses the original payment posting, restores the invoice as open, optionally adds NSF fee. Triggers customer-status change (no further sales until resolved).

Allowance / bad-debt reserve

Periodic reserve calculation (% of receivables, or per aging bucket). Manual journal typically; some customers automate via DMF and external calculation.

• Customer aging report: standard aging by bucket, per customer / per pool, currency / functional.
• Days Sales Outstanding (DSO): AR balance / (revenue / period days). Trend tracking shows collection effectiveness.
• Collection Effectiveness Index (CEI): (beginning AR plus credit sales minus ending total AR) divided by (beginning AR plus credit sales minus ending current AR). Measures actual collection performance.
• Bad-debt expense % of revenue: the strategic-level KPI for credit policy effectiveness.
• Collections Workspace KPIs: per-agent effectiveness, calls per day, promise-to-pay rate.

Power BI / Finance Insights

Built-in collections analytics with ML-based payment-prediction (when will this invoice pay) feeds prioritization and cash forecasting.

Expense parameters

Where: Expense management > Setup > General > Expense management parameters. Number sequences, default vendor (used as the AP vendor for the worker), receipt requirements (attach mandatory above $X), itemization rules, intercompany handling.

Expense categories & shared categories

Same two-tier model as Projects. Shared categories are cross-company (Airfare, Hotel, Meals, Mileage); per-legal-entity expense categories map shared categories to local ledger accounts and tax codes. Sub-categories (Domestic Hotel vs. International Hotel) refine reporting.

Expense policies

Where: Expense management > Setup > Policies > Expense report. Rules per category: limits ("Hotel above $300/night"), required fields, attendees required for meals, receipt attachment threshold. Policy violations can warn (worker may proceed with justification) or error (block submission).

Per diem rules

Per diem rates per location, with reductions for partial days, meals provided, lodging not used. Rates per region (US GSA rates can be loaded; international per CONUS / OCONUS or company policy).

Mileage rates

Per region / vehicle type. Tiered rates (first 5,000 miles at $0.65/mi, beyond at $0.55/mi). Tax rules per region (US IRS standard mileage vs. company rate).

Workers as expense filers

Each worker linked to an AP vendor (the reimbursement target). Vendor is per legal entity; intercompany expenses use the vendor in the worker's home company.

Delegates

Worker can delegate report creation to an admin / EA. Effective-dated; delegate sees the worker's expense list. Common pattern for executives.

Default financial dimensions

Position drives default cost center / department; expense report inherits but can be overridden per line. Project allocation is at line level.

Approval routing

Configured via workflow (Expense report workflow). Common: line manager > project manager (if project) > finance review (if over threshold). Position hierarchy publishing required for accurate routing.

Travel requisition (optional)

Pre-trip approval workflow with estimated costs. Once approved, drives downstream cash advance issuance and links to the eventual expense report. Mandatory in some governance models; many companies skip it for routine domestic travel.

Cash advance

Pre-trip cash issued (per diem, expected expenses). Posts as worker advance (debit) / cash (credit). Reconciled when expense report submitted; under-spend refunded, over-spend reimbursed via the report.

Expense report creation

Worker creates report (web or mobile), adds line per transaction. Each line: category, date, amount, currency, paid-by (personal funds vs. corp card), project, dimensions, attachment.

Receipt capture

Mobile app: photo of receipt, OCR extracts merchant / amount / date / category; Copilot capability proposes the expense line. Web: drag-drop attach. Multiple receipts per line for itemization (hotel folio split across nights / categories).

Itemization

Hotel folio of $1,200 split into Lodging $900, Meals $200, Internet $80, Tax $20. Each itemized line can have its own category / project / tax treatment.

Credit card imports

Corporate card transactions (VCF 4.0 or equivalent file) imported daily. Workers attach card transactions to expense lines (vs. typing manually). Reduces fraud risk and accelerates reporting. Unmatched card transactions trigger reminders.

Workflow design

Line-level approval (project manager approves only project lines) vs. header-level (one approver for the whole report). Combine via parallel branches in workflow.

Audit policies

Where: Expense management > Setup > Policies > Audit. Sample-based audit rules: random sampling, threshold-based, category-based. Adds an audit step in workflow for sampled reports.

Posting

Approved & posted reports generate:

• Vendor invoice (the AP-side liability for the worker reimbursement).
• Project transactions (if any project lines).
• Tax recovery (recoverable VAT / GST per category and policy).
• Card clearing entries (if corp-card paid; offsets the card statement liability).

Reimbursement

The vendor invoice becomes part of the next AP payment run; worker is paid via direct deposit or check from the AP module.

Project posting

Lines tagged to a project route to PMA on posting; cost posts at category cost rate, billable lines accrue revenue. Most common in services firms.

Intercompany expense

Worker in Company A incurs expense for project in Company B. F&O posts the expense in Company A and a corresponding intercompany journal in Company B (cost in B, IC payable to A). Requires intercompany configuration.

PO-funded T&E

For prepaid travel (corporate-booked airfare, hotel charged to ghost card), the cost goes through AP as a vendor invoice, not Expense. Avoid double-counting; train workers on the boundary.

Tax recovery

Recoverable VAT / GST extracted at posting based on category tax setup. Especially relevant for EU travel.

Modernized Expense experience

Microsoft introduced a redesigned Expense reports page (modernized list) and a mobile capture-first flow. Compatible with most existing setups; enable via Feature management.

OCR receipt capture

Photo > AI extracts amount, merchant, date, suggests category. Worker confirms, attaches to expense line. Reduces manual entry significantly.

Copilot in Expense (where available)

Summary of pending reports, anomaly detection ("3 dinners in one day"), policy violation explanations, Q&A on expense status. Rolling out in waves; check release notes.

Travel partner integrations

Concur Travel, Egencia, etc. integrate as data sources, populating expense reports from booked itineraries (no manual entry of the airfare leg).

Books (renamed from Value models / Depreciation books)

Where: Fixed assets > Setup > Books. Each book is a separate set of asset values for a specific reporting purpose. Common pattern: Corporate book (US GAAP / IFRS), Tax book (per country tax depreciation rules), Statutory book (local-GAAP). Each book has a posting layer (Current, Operations, Tax) controlling whether it hits the GL or sits parallel for reporting.

Note: pre-2019 versions had two separate constructs, Value models (which posted to the GL) and Depreciation books (tax / reporting only, no GL impact). Microsoft merged them into Books in version 10.0.x; the Posting layer on the book (Current / Operations / Tax / None) controls whether it posts to GL. Books can be configured to derive transactions to other books, so a single posting flows to multiple books simultaneously.

Depreciation profiles

Where: Fixed assets > Setup > Depreciation profiles. Methods include Straight line, Straight line life remaining, Reducing balance, Consumption, Factor, Manual. Depreciation conventions: half-year, full-month, mid-quarter, etc., applied at first transaction.

Fixed asset groups

Where: Fixed assets > Setup > Fixed asset groups. Group similar assets (Buildings, Vehicles, IT equipment, Furniture). Each group ties to default books, depreciation profiles, useful life, and posting profile (the GL accounts hit on acquisition / depreciation / disposal).

FA posting profiles

Where: Fixed assets > Setup > Fixed asset posting profiles. Define accounts per asset group per book per transaction type (Acquisition, Depreciation, Disposal sale, Disposal scrap, Write-up, Write-down). The most detailed posting profile in F&O.

Where: Fixed assets > Fixed assets > Fixed assets > New.

Required fields

• Fixed asset number: auto from number sequence per group, or manual.
• Group: drives book defaults, depreciation profile, useful life, posting profile.
• Name and description.
• Financial dimensions: cost center, department, location, cost-center-driven reporting.

Books per asset

Once the asset is created, each book inherits group defaults but can be overridden per asset. Set the Service date (placed in service), Acquisition date, useful life, and depreciation start date per book.

Parent assets and components

Group sub-components under a parent asset (a building's HVAC, elevator, plumbing as separate components under the Building parent). Allows component-level depreciation (required under IFRS) while still rolling up at the parent level.

Asset attributes

Custom attributes (asset tag, serial number, vendor, location, insured value, custodian) go on the Fixed asset record. Connect to physical asset tracking via Asset Management module if maintenance is in scope.

Manual acquisition

Where: on the asset, Books > Functions > Acquire. Direct journal entry; cost taken from a fixed amount or journal voucher.

Acquisition from a Purchase Order

Vendor invoice posted with an asset distribution (asset number on the invoice line). Posts to Asset clearing / bridge account, then the Acquisition proposal / Mass acquisition routine moves the cost into the FA cost account.

Acquisition proposal

Where: Fixed assets > Journal entries > Fixed asset journal > Lines > Proposals > Acquisition proposal. Pulls invoice lines from AP into the FA journal for capitalization. Bulk-process all asset acquisitions efficiently.

Acquisition from a project

Capital project accumulates cost as CIP (Construction in Progress); on placed-in-service, project Eliminate / Capitalize step transfers cost from CIP to FA cost. See Project to profit accounting examples.

Acquisition from inventory

Move stocked items into FA via inventory transfer journal that issues from inventory and acquires the asset. Useful when assembling assets from spare parts or transferring demo equipment.

Depreciation proposal

Where: Fixed assets > Journal entries > Fixed asset journal > Lines > Proposals > Depreciation proposal. Generates depreciation lines for selected assets and books based on the current period and depreciation profile. Review, then post.

Value adjustments

Write-up (increase NBV), write-down (decrease NBV, impairment), value correction (fix prior errors). Each posts to a dedicated account on the posting profile and is reflected in the asset's transactions and the depreciation schedule.

Asset transfer

Move asset between cost centers / departments / locations via the Transfer fixed asset routine. Natural account unchanged; only financial dimensions move. Future depreciation hits the new dimension.

Bonus depreciation and tax-specific runs

For tax books, F&O supports bonus depreciation (US Section 168k), Section 179, and various country-specific accelerated depreciation rules via depreciation profiles and bonus depreciation setup.

Mass updates

Bulk update useful life, depreciation method, posting accounts across many assets via the Mass update workspace. Critical for handling regulatory changes that affect a whole asset class.

Where: Asset leasing > Leases > Lease summary. The Asset leasing sub-module (added post-2018 to support ASC 842 and IFRS 16) automates lease accounting:

• Lease creation: capture lease terms, payment schedule, discount rate, classification (Finance vs Operating).
• Initial recognition: auto-generates the right-of-use (ROU) asset and lease liability; books the journal at commencement.
• Monthly posting: amortization of ROU asset, interest accretion on liability, payment recognition.
• Modifications: remeasurement journals when lease terms change.
• Transition: pre-built tools for moving from operating-lease (off-balance-sheet) accounting to ASC 842 / IFRS 16.

Without Asset leasing, this entire flow is manual journal-driven and error-prone, recommend turning the module on if leases are material.

Disposal, sale

Two paths: post a Disposal-sale journal in the FA journal directly (proceeds taken from a customer record or main account), or invoice the buyer through AR Free-text invoice with the asset reference (the FA journal generates automatically from the AR invoice). Net of accumulated depreciation and proceeds = gain or loss.

Disposal, scrap

Asset retired with no proceeds. Post via Disposal-scrap on the FA journal. Net book value at disposal = loss on disposal.

Partial disposal

For partial sale of an asset (selling 50% of a building, for example), F&O supports the Partial disposal feature, recalculates remaining cost basis and depreciation prospectively.

Multi-book disposals

Disposal must be processed per book; the gain/loss differs between corporate and tax books because depreciation differs. Check each book carries the disposal correctly before closing.

• Fixed asset register: the master list of assets with their cost, accumulated depreciation, NBV, status. The single most-asked-for FA report.
• Depreciation expense report: by group, by book, by period.
• Roll-forward: opening balance, additions, depreciation, disposals, closing balance for a period (per group, per book). The schedule auditors review.
• Fixed asset note disclosure: the details required for financial-statement footnotes.
• Country-specific tax depreciation reports: India, Japan, Mexico, Brazil, several EU countries ship pre-built tax reports as Electronic Reporting configurations.
• Power BI: for executive dashboards on capital deployment, depreciation trend, asset age.

Ledger

Where: General ledger > Ledger setup > Ledger. Per legal entity, you set the chart of accounts, account structures, accounting currency, reporting currency, exchange rate type, fiscal calendar. Accounting currency is the GL functional currency; reporting currency is a parallel translation. Both are set at company creation and cannot be easily changed once transactions exist.

Chart of accounts

Where: General ledger > Chart of accounts > Accounts > Main accounts. Cross-company chart, shared across legal entities that use the same COA. Each main account has type (Asset, Liability, Equity, Revenue, Expense, Balance, Total, Profit and loss, Reporting), category (used for financial reports), and posting controls (Do not allow manual entry, Active, Suspended).

Fiscal calendar

Where: General ledger > Calendars > Fiscal calendars. Defines fiscal years and periods (12, 13, or custom). 4-4-5, 4-5-4, 13-period calendars are all supported. The calendar links to the ledger; multiple legal entities can share or have separate calendars. Year-end roll-forward generates the new year.

Exchange rate types and currencies

Where: General ledger > Currencies. Exchange rate types separate spot, average, budget, and reporting rates. Rates can be imported (per OANDA, ECB, central bank feeds via Electronic Reporting / dual-write). Multi-currency entities must define rate types for transactional, revaluation, and reporting purposes.

Financial dimensions

Where: General ledger > Chart of accounts > Dimensions > Financial dimensions. Custom dimensions (department, cost center, project, BU, location) plus system-backed dimensions (Worker, Vendor, Customer, Item) that resolve from existing master records. Each dimension is shared cross-company, used per ledger via the account structure.

Account structures

Where: General ledger > Chart of accounts > Structures > Configure account structures. Define which combinations of main account + dimensions are valid. Per structure:

• Up to 11 segments: 1 main account + 10 dimensions. Advanced rules can add up to 5 more for a total of 16.
• Main account first (or early): drives validation performance.
• Allowed value lookups per segment: ranges (1000..1999), wildcards, fixed values, derived values.
• Draft > Activate workflow: changes go through draft state and are validated before activation; once active, structure cannot be deleted while in use.
• One main account, one structure: a given main account cannot appear in more than one active account structure.

Advanced rules

Where: General ledger > Chart of accounts > Structures > Advanced rule structures. Add conditional segments based on main account ranges. Example: when main account is 5000-5999 (Travel expenses), add a Project dimension. Apply via Advanced rules on the parent account structure, with criteria (main account between X and Y).

Common gotcha: advanced rules apply after the base structure segments, alphabetically. If the base structure already has the dimension fixed, the advanced rule won't override it. Test with sample postings during design.

Fixed, derived & balancing dimensions

• Fixed dimension: set on the main account (per legal entity override). Forces a specific value regardless of the entered code (e.g., main account 4100 always uses Department = 100).
• Derived dimension: populates one dimension based on another (e.g., Cost Center derived from Department).
• Balancing dimension: auto-creates due-to / due-from offset entries when a single voucher straddles different values of one dimension. Used for inter-department or inter-business-unit transactions to keep each segment balanced.

Default dimensions & the defaulting hierarchy

Every master record (vendor, customer, item, worker, position, project, FA, bank, posting profile, journal name) carries default financial dimensions. At posting, F&O resolves the dimension values in this order:

1. Fixed dimension on the main account (always wins).
2. Master record (vendor / customer / item / worker / project) on the source document.
3. Posting profile dimensions, if applicable.
4. Journal header / source-document header defaults.
5. Account structure validation (rejects invalid combinations).
6. Advanced rules (inject conditional segments).
7. Balancing dimension (auto-offsets if needed).

Most "wrong dimension on a posting" issues come from misunderstanding this order. Default Dimension Templates (per worker / position / customer / vendor) standardize the master-record defaults across the org.

Dimension sets and views

Dimension sets aggregate dimensions for reporting. Trial balance and Financial Reporter use them to slice the ledger by chosen dimensions. Pre-build the sets you'll need before close to avoid scramble.

Lean COA philosophy

The modern approach: small COA (a few hundred main accounts), let dimensions carry detail. Old-school approach of department-encoded account numbers (5,000+ accounts) breaks reporting and complicates account structures. Push back on customers who insist on the old model.

The two-stage posting model

Modern F&O uses an accounting framework where source documents (PO, SO, vendor invoice, free-text invoice, expense report, project invoice proposal, asset acquisition) generate accounting distributions before posting, then a subledger journal that journalizes to the GL. One-to-one voucher reference between subledger and ledger.

Accounting distributions

Where: on a source document line, Financials > Distribute amounts (or via the document, View distributions). Shows the proposed debits and credits before posting. Lets users override the default GL account and dimensions per line, with validation against the account structure. Distributions are calculated when amounts and dimensions on the source change.

Subledger journal

Where: Subledger journal button on the source document, or General ledger > Periodic tasks > Subledger journal entries not yet transferred to general ledger. The intermediate accounting record between source document and ledger voucher. Visible for review / preview before posting.

Documents pending accounting

Where: General ledger > Periodic tasks > Documents pending accounting. Shows source documents with subledger entries that haven't yet posted to GL (for performance, posting can be deferred to batch). The reconciliation point: nothing should age long here.

Why this matters for consultants

• Lets users see and adjust the accounting impact before posting, reducing reversal journals.
• Enables distribution overrides (split a PO line across multiple departments / projects with different dimensions).
• Decouples source-document posting from GL load (performance feature for high-volume environments).
• Improves audit trail: every ledger voucher traces back to a single source document.

Every subledger has a posting profile that maps subledger transactions to GL accounts. They share a Table / Group / All priority pattern:

• AP Vendor posting profile: vendor > vendor group > all. Drives AP control account, settle account, prepayments, arrival / offset.
• AR Customer posting profile: customer > customer group > all. Drives AR control, settle, prepayments.
• Inventory posting profile: item > item group > category > all. Drives every inventory transaction (PO receipt, SO COGS, transfers, count adjustments, WIP).
• Fixed asset posting profile: asset group > book > transaction type. The most granular profile in F&O.
• Project posting profile: per project group, drives WIP, accrued revenue, billed revenue, deferred revenue accounts.
• Bank posting (Cash and Bank): per bank account, drives the GL account behind the bank.
• Sales tax ledger posting groups: per tax code, drives tax payable / receivable.
• Production posting: uses the Inventory posting profile (Production tab) keyed to item groups for picking list, RAF, WIP, variances.
• Cost accounting posting (legacy): retired in favor of the Cost accounting module's own ledger.

For each profile, design at the Group level (vendor group, customer group, item group, asset group). Specific (Table-level) overrides only when business logic demands. Set rows for Item-code = All / Account-code = All as catch-alls so no transaction can fail to find a row.

Journal types

• Daily journal (General ledger > Journal entries > General journals): manual journal entries.
• Periodic journal: templates for recurring entries (monthly accruals, allocations).
• Allocation journal: generated from ledger allocation rules.
• Foreign currency revaluation journal: auto-generated by the FX reval routine.
• Year-end closing journal: generated at fiscal year close to roll P&L into retained earnings.

Journal name configuration

Where: General ledger > Journal setup > Journal names. Each name controls journal type, default offset account, voucher series, approval workflow, posting layer, and whether reversal is enabled.

Ledger allocation rules

Where: General ledger > Allocations > Ledger allocation rules. Define source (which accounts/dimensions to pull) and destination (where to push) with method (fixed percentage, fixed weight, basis, formula). Run periodically to allocate overhead, shared services, and similar to operating departments.

Posting layers

Three posting layers: Current (operational, reportable), Operations (statistical), Tax (tax-book postings parallel to current). Used for multi-book reporting where tax depreciation differs from book depreciation, for example.

Period status

Where: General ledger > Periods > Ledger calendars. Each period per module per legal entity has a status: Open (everyone can post), On hold (only listed users can post), Closed (no posting, can be reopened), Permanently closed (no posting, cannot be reopened). Use Permanently closed only after audit sign-off.

FX revaluation

Where: General ledger > Periodic tasks > Foreign currency revaluation. Revalues open balances in foreign currencies at period-end. AP and AR have their own routines for sub-ledger balances; GL revaluation handles GL accounts directly.

Year-end close

Where: General ledger > Periodic tasks > Year-end close. Closes P&L accounts to retained earnings, generates opening transactions in the new year. Run only after subledgers are fully closed and trial balance is finalized.

Financial period close workspace

Where: General ledger > Period close > Financial period close. A workspace introduced to coordinate close tasks across modules and legal entities, with task templates, dependencies, owners, and status tracking. Replaces ad-hoc Excel-based close calendars.

Intercompany accounting

Where: General ledger > Posting setup > Intercompany accounting. Set up due-to / due-from accounts per legal entity pair. When journals span legal entities (intercompany journal entry, intercompany sales / purchase), F&O auto-generates the IC offset entries to keep each entity balanced.

Consolidation

Two patterns:

• Consolidation legal entity (online): a dedicated consolidation entity that pulls translated balances from each subsidiary in real-time via dimension mapping. Used when entities run on the same F&O instance.
• Consolidation (import): import balances from external systems into the consolidation entity. Used in mixed environments.

Eliminations live as journals in the consolidation entity, see Record to Report accounting examples.

Currency translation for consolidation

Translate subsidiary balances at appropriate rates per FX policy (current rate for assets/liabilities, historical or average for income statement, historical for equity). The translation difference posts to a Cumulative Translation Adjustment (CTA) account in equity.

Trial balance

Where: General ledger > Inquiries and reports > Trial balance. Per period, per dimension set. The most-used report in finance, ties to subledger aging totals.

Voucher transactions

Drill from trial balance to voucher to source document. The audit trail every auditor wants.

Financial Reporter

Embedded report designer for income statements, balance sheets, cash flow, custom statutory reports. Uses Row, Column, and Reporting Tree definitions. Less full-featured than the legacy Management Reporter standalone tool, but no separate deployment.

Power BI and Finance Insights

Embedded Power BI workspaces for ledger analytics. Microsoft also ships Finance Insights / agents (newer additions) that surface anomaly detection on ledger data, vendor invoice forecasting, and customer payment predictions, capabilities continuously expanded under the Copilot umbrella.

HR parameters & shared parameters

Where: Human resources > Setup > Human resources parameters (per legal entity) and Shared parameters (cross-company defaults). Shared parameters drive global worker number sequence and the worker / position relationships that span companies.

Job, position, worker hierarchy

• Job: generic role definition (Senior Accountant, Warehouse Associate). Job-level skills, education, certificates.
• Position: a specific instance of a job at a department / location, with effective dates. The position holds the financial dimension default that tags transactions.
• Worker: the individual (employee or contractor). Workers are assigned to positions over time.

Departments & operating units

Departments are operating units (configured in Organization administration). Position > Department links the position into the org hierarchy that drives reporting and approvals.

Worker types

Employee (formal hire, eligible for payroll / benefits) vs. Contractor (limited workflow, typically no payroll). Cannot mix freely; transition employee <> contractor changes downstream behavior.

Hire process

Where: Human resources > Workers > Hire. Wizard captures personal info, address, contact, compensation, position assignment, default financial dimensions. Generates worker number and personnel number per legal entity.

Position assignments

Effective-dated. A worker can hold multiple positions (primary plus additional); a position can be held by one worker at a time (with effective-date succession). Reporting line follows the primary position.

Worker financial dimensions

Defaults flow: position dimensions > worker dimensions > transactions. Used for: payroll cost distribution, expense report defaulting, time entry posting. Set carefully; mid-year changes reroute costs.

Personnel actions

Optional workflow framework for hire / transfer / terminate / change-position events. Not required, but useful for HR-driven approval and audit trails.

Termination

Sets termination date, ends position assignment, optionally inactivates user. Termination is reversible (rehire) but should be intentional; many downstream impacts (workflow delegations, security).

Leave plans

Where: Human resources > Leave and absence > Leave plans. Define accrual rules (per period, fixed amount or formula), entitlement, carryover policy, leave year boundaries.

Leave types

Vacation, Sick, Personal, Bereavement, Jury duty, etc. Each tied to a leave plan; some unpaid and not accruing.

Leave requests

Worker self-service via Employee self-service workspace. Approval workflow to manager. Approved requests reduce balance and feed Payroll (if used) and time-tracking.

Leave balance

Real-time per worker per leave type, with accrued / used / available. Year-end carryover or forfeit per plan rules. Adjustments via journal for corrections.

Where: Human resources > Compensation > Fixed plans and Human resources > Compensation > Variable plans.

Compensation plans

Two types: Fixed (base pay) and Variable (bonus, equity). Each tied to a structure (grid / step / band) defining ranges per level.

Grids and reference points

Grid defines pay ranges by level / region; reference point sets the "midpoint" used as the baseline for percent comparisons (compa-ratio, range penetration).

Compensation events

Mass cycle for annual increases, merit cycles, promotions. Manager allocates within budget; HR approves. Posts new comp records effective-dated. Required for any company doing structured comp planning.

Eligibility rules

Per plan: who's eligible (job level, department, country). Drives cycle inclusion and self-service visibility.

Employee self-service

Browser / Teams workspace: profile, time-off, expense, learning, performance, pay statements (if Payroll). Mobile-friendly.

Manager self-service

Team view: direct reports, approve requests (leave, expense, timesheet), team competencies, comp planning. The most-used HR workspace by line managers.

Performance & goals

Optional module: goals, reviews, 1:1 templates. Lighter than dedicated talent products (Workday, SuccessFactors); often replaced by ISVs for sophisticated talent processes.

Payroll

F&O Payroll (US-only native) reads worker, position, compensation, earnings codes, tax setup directly. For other regions, HR data flows via integration to Ceridian Dayforce, ADP, Workday, or similar.

Project resources

Workers tagged as resources for Project Management. Skills, calendar, hourly cost rate flow into project planning and revenue calculation.

Expense Management

Worker linked to user; expense reports default to worker's default dimensions. Approval workflow uses position-based hierarchy.

Workflow & signing limits

Position hierarchy (configured in Organization administration) drives approval routing and signing-limit checks across PR, PO, AP invoice, expense.

Dual-write to Dataverse

Worker entity syncs to Dataverse / Customer Engagement, allowing CE customer-service apps to recognize internal users / agents.

Inventory hierarchy

Three levels: Site (a mandatory financial inventory dimension that drives ledger posting splits and ties to a legal entity) > Warehouse (a physical or virtual stocking location) > Location (specific bin / aisle / rack within a warehouse).

• Site is the only mandatory inventory dimension and is always financially tracked; carries default financial dimensions and ties to the legal entity.
• Warehouse can be basic (simple storage) or advanced WMS-enabled (full work / wave / mobile flow).
• Location is required for advanced WMS; optional but recommended for basic warehousing.

Basic vs. advanced WMS

The single most consequential design decision in SCM. Basic warehousing handles simple put-away and picking with manual journals; advanced WMS adds work creation, wave templates, mobile execution, license plates, location directives. Once a warehouse is enabled for advanced WMS, transactions in that warehouse are locked into the WMS path.

Inventory parameters

Where: Inventory management > Setup > Inventory and warehouse management parameters. Site activation, default journal names, reservation behavior, on-hand list defaults, FX revaluation defaults, batch / serial number control settings.

Item groups

Where: Inventory management > Setup > Inventory > Item groups. Item groups are the master-data bridge between released products and the inventory posting profile. Every released product must be assigned an item group (the field is mandatory on the released product). The group is what the inventory posting profile keys on for the "Group" account-code level. Item groups are distinct from Item model groups: item groups drive ledger posting, item model groups drive costing method / stocked-status / reservation behavior.

Designing item groups

Group items by accounting behavior, not procurement category or marketing taxonomy. Common splits:

• Raw materials (manufactured goods inputs, hits raw-material inventory account).
• Finished goods (own production output).
• Trade goods / Resale (purchased for resale).
• Service items (non-stocked, no inventory account).
• Spares / MRO (maintenance items).
• Capital items (will be capitalized as fixed assets).

10-20 item groups is typical for mid-market; large manufacturers go higher when they need multiple raw-material pools (chemicals vs. metals vs. components) reporting separately on the balance sheet.

Inventory posting profile

Where: Inventory management > Setup > Posting > Posting. The matrix that maps every inventory transaction to a GL account. Three keying levels per row:

• Item code: Table (specific item), Group (item group), All, Category (procurement category).
• Account code: Table (specific customer / vendor), Group, All.
• Posting type: the transaction (Purchase expenditure for product, Cost of purchased materials received, Cost of goods sold, Issue, Receipt, Revenue, Discount, WIP, Profit/Loss, etc.).

Most companies set rows at the Item-code = Group level (per item group) for normal posting types and Item-code = All for the catch-all rows. Specific overrides at Item-code = Table only for exceptions.

Posting type cheat-sheet

• Purchase expenditure for product + Purchase accrual: PO product receipt (GRNI accrual to liability).
• Cost of purchased materials received + Cost of purchased materials invoiced: PO product-receipt vs. invoice variance handling.
• Issue / Receipt: inventory-only journals (transfer, movement).
• Cost of units delivered / Cost of units invoiced: SO packing slip / invoice (relieves inventory, posts COGS).
• Revenue / Discount: SO invoice (debit AR, credit revenue).
• WIP: production order picking list / RAF.
• Profit / Loss: counting variances, write-offs.

Which posting types fire depends on the Item model group toggles (Post physical inventory, Post financial inventory, Accrue liability on product receipt). Misalignment between item-model-group toggles and posting-profile rows is the #1 cause of "missing combination of financial dimensions" errors at posting.

Reconciliation discipline

The inventory value report (per item / warehouse / dimension) must tie to the inventory control accounts in the GL. Mismatch usually means: (1) manual journal hit the inventory account directly, (2) posting profile gap (a rare combination has no row matching), or (3) an item moved to a new group mid-period. Reconcile every period close.

Where: Product information management > Setup > Dimension and variant groups > Storage dimension groups / Tracking dimension groups.

Storage dimensions

Site, Warehouse, Location, Inventory status, License plate. Define where inventory physically is. Storage dimension groups configure which dimensions are mandatory / coverage-relevant / financial-tracking-relevant per item.

Tracking dimensions

Batch number, Serial number. Define what specific unit of inventory you're tracking. Tracking dimension groups control whether batches / serials are required at sale, purchase, production.

Inventory status

A storage dimension introduced for advanced WMS that flags whether stock is Available, On hold (quality), Blocked (damaged), Transit. Drives whether the stock can be picked without further intervention.

The dimension lock-in

Storage and tracking dimension groups are set per item and effectively cannot be changed after transactions post. Adding a tracking dimension after go-live = data migration project. Decide for the product family during requirements, not per SKU.

Coverage groups (planning)

Inventory dimensions also drive Master Planning behavior, see Master Planning module.

F&O ships several inventory journal types, each with a specific purpose:

• Movement journal: manual stock adjustment with custom offset account. Use for ad-hoc stock changes that don't fit other journals.
• Inventory adjustment / Profit-Loss journal: stock changes that should hit a P&L account directly (write-offs, found stock).
• Transfer journal: move stock between warehouses / locations / dimensions within the same legal entity. No GL impact unless dimensions changed.
• BOM journal: light manufacturing assembly without a production order. Components consumed, parent item produced.
• Counting journal: physical inventory count. Variances post to count adjustment account.
• Tag counting journal: ticket-based counting for warehouses that use physical count tags.

Transfer orders

Where: Inventory management > Outbound orders > Transfer orders. Inter-site or inter-warehouse transfers with formal Ship and Receive events. Optional Inventory in transit handling for cut-off control. Use Transfer orders when timing matters; Transfer journals when the move is instantaneous.

Manual vs. automatic

Manual: user explicitly reserves inventory for a sales order line. Automatic: F&O reserves on order entry per the customer / item / order policy. Auto-reservation feels safer but locks stock that other orders may need; tune carefully.

Reservation hierarchy

Defines which dimensions are reserved at what time. Default hierarchy: Site / Warehouse / Inventory status, then Location at picking, then Batch / Serial at issue. Custom hierarchies are possible but rarely needed.

Marking

Stronger than reservation: a hard link between a sales order line and a specific inventory transaction (typically used to maintain cost flow integrity, marking a sale to a specific PO receipt for FIFO accuracy).

Master planning impact

Reservations consume planned supply, so when you reserve 100 units for a customer, MRP doesn't propose new supply for that demand. Over-reservation can cause planning to miss real shortages.

Counting plans

Where: Inventory management > Setup > Inventory > Counting. Schedule counts by ABC class, by frequency, by exception (every time stock hits zero). Mature warehouses count perpetually rather than once a year.

Counting journal flow

Generate counting journal > print count tickets > physical count > enter counted quantities > review variances > post adjustments. Variance accounts split between shrinkage, scrap, mis-count if reason codes are configured.

Inventory-to-GL reconciliation

Inventory valuation report (per item, per warehouse, per dimension) must tie to the inventory control accounts in the GL. Mismatch means manual journals hit the inventory account or a misposted transaction. Reconcile every period close.

Inventory closing

For costing methods that require it (FIFO, weighted average), Cost Management's inventory close finalizes unit cost for the period and adjusts COGS / inventory value for any open transactions. See Cost Management module.

• On-hand list: current stock by item, warehouse, location, batch, serial. The most-used inventory inquiry.
• Inventory aging: stock by age bucket; identifies slow-moving / dead stock candidates.
• Inventory value report: stock at cost per item / warehouse / dimension. Reconciles to GL.
• Inventory transactions: all transactions for an item; the audit trail.
• Cycle count statistics: count accuracy by warehouse / period.
• Power BI: for executive inventory dashboards (turns, days of supply, ABC mix).

Landed cost parameters

Where: Landed cost > Setup > Landed cost parameters. Number sequences (voyage, container, journey), default journey template, posting accounts for accrued landed cost, default cost variance thresholds.

Cost types

Where: Landed cost > Setup > Costing setup > Cost types. Each cost component (Ocean freight, Customs duty, Insurance, Brokerage, etc.) is a cost type with:

• Apportionment basis: Quantity, Weight, Volume, or Value (CIF basis is common for duty).
• Posting accounts: accrued landed cost (debit at receipt) and clearing (credit on AP invoice match).
• Vendor link: default vendor for that cost type (forwarder, customs broker, insurer).

Cost templates & auto cost

Templates predefine cost types and rates per route / origin / commodity. Auto cost rules add costs automatically when a PO line / container is added to a voyage. Reduces manual data entry significantly.

Journey templates

Define typical legs (origin port, ocean leg, destination port, drayage to DC) with default lead times and carriers. Used for planning ETD / ETA dates and accrual triggers.

Voyage

The shipment header. Holds journey, vessel name, ETD / ETA, status (Created → In transit → Arrived → Closed). Multiple POs and multiple containers can roll up to one voyage.

Shipping containers

Physical containers (TEU / FEU equivalents). PO lines are assigned to specific containers; auto cost can apportion container-level charges (drayage, terminal handling) to the lines inside.

Folio / customs entry

Folio is the customs / import declaration document number, captured on the voyage for audit / regulatory traceability.

Voyage statuses

Status transitions trigger different actions: In transit creates the in-transit inventory; Arrived reverses in-transit and posts to inventory at receiving warehouse.

Standard voyage flow

1. PO created and confirmed with origin vendor; PO lines added to a voyage.
2. Voyage set to In transit; in-transit inventory increments at the destination warehouse.
3. Estimated landed costs (auto cost) accrue on the voyage.
4. Voyage Arrived; in-transit reversed, inventory received, accrued landed cost capitalized to inventory cost.
5. AP invoices for freight / duty / insurance arrive over weeks; matched to voyage cost lines.
6. Voyage closed when all costs invoiced and variances recognized.

Apportionment math

Cost / Total apportionment basis × line apportionment basis. Example: $5,000 freight, total weight 10,000 kg, line A is 3,000 kg; line A absorbs $1,500 freight. Each cost type apportions independently per its configured basis.

AP invoice matching

Freight invoice from forwarder posted to landed-cost cost line, not directly to GL. F&O matches invoice amount to accrued amount; difference posts to landed cost variance. Three-way match equivalent for landed costs.

Customs entry & duty

Duty rates per HS code, per origin country (free trade agreements). F&O can store the rates and apply to PO lines, or rates can be flat per shipment.

Receipt accounting

At Arrived: inventory debited at PO cost plus apportioned estimated landed cost. Credits split between AP accrual (PO cost) and accrued landed cost (estimate).

Invoice matching accounting

Vendor invoice for freight: AP credit, accrued landed cost debit. Difference (actual vs. accrued) posts to landed cost variance account; configurable to also adjust inventory cost (rebalance) for material amounts.

Cost variance close

Voyage close finalizes variances and locks the voyage. Periodic variance review identifies vendors / lanes consistently mis-estimated and feeds back into cost templates.

• Voyage cost report: all costs (estimated, accrued, actual) per voyage; the audit document.
• Landed cost variance: per cost type, per vendor, per route; identifies estimate accuracy.
• Item landed cost analysis: per-item average landed cost over time; drives sourcing decisions.
• Open voyages aging: voyages with arrived status but unmatched invoices; the AP/GL reconciliation tool.

Justified when

• Significant import volume; landed cost is >5-10% of PO cost.
• Multiple cost components per shipment (freight, duty, insurance, brokerage).
• Cost components arrive on separate vendor invoices, days/weeks after the goods.
• Need to cost-allocate at line level, not just lump on the PO.

Overkill when

• Domestic-only purchasing; one freight charge per PO.
• Vendor sells DDP (delivered duty paid); all cost is in PO price.
• Use Charges (Charges codes) on the PO instead, with debit type Item to roll into inventory cost or Ledger to expense directly.

Pitfalls

• Voyages left open: AP team forgets to match against the voyage; AP entry hits a generic freight account, voyage stays in accrual.
• Cost templates not maintained: rates from year one still in place; estimates drift; variances grow.
• Apportionment basis mismatch: apportioning freight by quantity for items with very different sizes overstates cost on small items.

Planning Optimization (current)

Runs in a dedicated Azure service. Reads F&O data, computes plans, writes planned orders back. Benefits: 10x+ performance, runs during business hours without locking, supports incremental planning, and the only engine receiving new investment.

Legacy MRP (in-process, deprecated)

Runs inside F&O batch framework. Limited by SQL contention; typically scheduled overnight. Microsoft formally announced deprecation in October 2023 with a multi-year removal timeline; new implementations must use Planning Optimization. Use the Master Planning fit-analysis tool to confirm coverage of your scenario before migrating existing customers.

Fit analysis

Where: Master planning > Setup > Planning Optimization > Fit analysis. Runs against your data and reports unsupported scenarios (some legacy features, e.g., advanced inventory close coordination, may not yet be in scope). Run early in design; use to plan migration.

Demand forecasting

Separate module for statistical forecasting (Azure ML based). Generates baseline demand forecasts that feed Master Planning as forecast demand. Optional but powerful for distribution / make-to-stock environments.

Plan types

• Static plan: the operational plan, frozen from the last planning run; what shop floor and buyers see. Most companies have one static plan.
• Dynamic plan: what-if plan, can be regenerated continuously. Used for scenario testing without disturbing operations.
• Forecast plan: longer-horizon plan based on forecast demand only, drives material commitment and capacity reservation.

Master plan parameters

Where: Master planning > Setup > Plans > Master plans. Defines: include forecast yes/no, include sales orders, include intercompany, planning horizon (days), action message horizon, futures horizon, freeze time fence per coverage group.

Planning Optimization configuration

Where: Master planning > Setup > Planning Optimization. Connect F&O to the Planning Optimization service via the Power Platform admin connection. After setup, plans run against the service rather than local batch.

Master planning parameters

Where: Master planning > Setup > Master planning parameters. Number sequences, default plans for sales / purchase orders, BOM version requirements, available-to-promise (ATP) settings.

Coverage groups

Where: Master planning > Setup > Coverage > Coverage groups. The most important master-planning configuration. Per-item or per-item-group, defines:

• Coverage code: Period (lot per period), Requirement (lot per requirement), Min/Max (reorder point with target), Manual (planner controls).
• Coverage time fence: how far out the engine looks for demand.
• Negative / positive days: tolerance for using earlier / later supply.
• Action message time fence: how far out to suggest reschedule actions.
• Futures time fence: how far out to compute delay impacts.
• Freeze time fence: period inside which the plan is frozen (no new planned orders).

Item-coverage overrides

Item-level coverage overrides on the released product (per warehouse) refine planning per location. E.g., regional DC has min/max, central plant has requirement coverage.

Lead times & throughput

Purchase lead time (vendor), production lead time (manufacturing), transfer lead time (between sites). Throughput per resource (capacity) feeds finite scheduling. Inaccurate lead times produce inaccurate plans; this is the most common cause of planning complaints.

Safety stock

Per item or via the Safety stock journal (recalculate periodically). Optional dynamic safety stock based on forecast demand variability via Demand Forecasting.

Run modes

• Regeneration: full plan rebuild. With Planning Optimization, fast enough to run during the day.
• Net change (legacy): only items with changed demand / supply re-planned. Faster on legacy but can miss cascading impacts.
• Incremental planning (Planning Optimization): Microsoft's modern equivalent of net change, designed to run continuously.

Filters

Filter by item, item group, coverage group, warehouse. Useful for partial runs (single warehouse, ABC class A items). Less needed with Planning Optimization given the speed.

Firming planned orders

Planned orders are suggestions; firming converts them to actual purchase / production / transfer orders. Where: from the planned orders list, Firm action. Manual review (planner workstation) is best practice; automatic firming is risky for anything but pure replenishment.

Available to promise (ATP)

Sales-side calculation: when can we promise this order. Pulls from forward supply (existing PO / planned orders). Configurable per item; not all sales scenarios use ATP.

Action messages

Suggestions for existing orders: advance, postpone, increase, decrease, cancel. Generated when supply timing or quantity differs from demand. Planner reviews and accepts / rejects. Where: Master planning > Planned orders > Action messages.

Futures messages

Notifies of demand that cannot be met by the requested date given current lead times. The "we're going to be late" message. Triggers escalation to expedite, find alternate supply, or notify customer.

Pegging

The trace of supply <> demand: which sales order is this planned PO covering, which BOM line drives this raw material need. Pegging tree shows multi-level upstream / downstream. Critical for planner triage.

Planner workspace

Modern UI: filtered planned orders, action messages by priority, KPIs (on-time, planning accuracy), bulk firm / accept actions. Better experience than the older list pages.

Planning Optimization metrics

Run history with duration, items planned, actions generated. Available in the Lifecycle Services dashboard for the Planning Optimization service. Use to track plan stability and engine health.

Operational KPIs

• Forecast accuracy (forecast vs. actual demand).
• On-time delivery from planned vs. confirmed dates.
• Inventory turn vs. service level.
• Planner action volume (high volume signals master data issues, not planner laziness).

Common pitfalls

• Lead time decay: initial lead times are estimated, never updated; over time the plan drifts.
• Coverage groups too coarse: one coverage group for everything; results in either overstock or stockouts.
• Forecast not consumed: when sales orders don't consume forecast (parameter not set), the plan double-counts.
• Frozen plans not refreshed: static plan held too long without regeneration; supply diverges from demand.

Legal entity

A company / organization that posts to a separate ledger and reports separately. Identified by a Data Area ID (up to 4 characters; effectively immutable once transactions exist). Legal entity holds: ledger, currency, fiscal calendar (chosen, not unique), tax jurisdiction defaults, country / region context.

Choosing legal entities

One per legal company filing separate financials. Don't create LEs for divisions, branches, or product lines, those belong as operating units or financial dimensions. Adding an LE later is supported but expensive (master data setup, fiscal calendars, opening balances, security).

Operating units

Subdivisions inside a legal entity that aren't LEs themselves. Types:

• Department: functional grouping (Engineering, Sales).
• Cost center: budgetary unit.
• Business unit: P&L unit, often with its own management.
• Value stream: lean-manufacturing flow.
• Retail channel: sales channel (used by Commerce).

Operating units <> financial dimensions

Operating units are typically also financial dimensions, allowing GL transactions to be coded to them. Set up the OU and the dimension together; many implementations forget the dimension link, then can't report by OU.

Where: Organization administration > Organizations > Organization hierarchies.

Hierarchy purposes

One hierarchy can serve multiple purposes; common purposes:

• Organization chart: reporting visualization.
• Centralized payments: cash-pool flow across LEs.
• Security: XDS scope by hierarchy.
• Signing limit: approval routing per position level.
• Retail assortment: assortments scoped to a hierarchy node.

Publishing

Hierarchies must be published with a draft > published transition (effective-dated). Workflow / signing limits use the published version. Edits create a new draft until published.

Day-one essentials

Most implementations need: organization chart (positions), signing limit (approval), security (XDS where relevant). The others can be added later. Don't over-design hierarchies for hypothetical future uses.

Position vs. department hierarchy

Hierarchy can be over positions (one position per node, ideal for approval) or departments (org structure, useful for financial reporting). Multiple hierarchies coexist; pick the right basis per purpose.

Global address book (GAB)

Cross-company master of parties (organizations, persons). One party can play multiple roles: a single party can be Customer in LE A, Vendor in LE B, Worker in LE C.

Party records

Holds name, address(es), contact info, type (Person / Organization), language, profile image. Customer / vendor / worker records reference the party for shared data.

Party roles

• Customer: per LE, with AR-specific data (terms, credit limit).
• Vendor: per LE, with AP-specific data (payment terms, banking).
• Worker: cross-LE if shared services; per-LE personnel number.
• Contact: for sales/marketing.
• Competitor, prospect: CRM roles.

Address purposes

Where: Organization administration > Global address book > Address and contact information setup > Purpose. Each address on a party / customer / vendor / worker is tagged with one or more purposes:

• Invoice: appears on invoice headers.
• Delivery: ship-to address; drives sales-tax destination, transit time.
• Business: primary location.
• Payment / Remit-to: where to send payment.
• Statement: where customer statements go.
• Service: for service management dispatch.
• Other: custom purposes the company defines.

Address purpose drives which address is used per document. Misconfigured purposes cause invoices to mail to the warehouse, or sales tax to compute on the wrong jurisdiction. Each party can have multiple addresses with different purposes; one is flagged as the primary per purpose.

Multiple address books

Beyond the GAB, you can define address books as visibility scopes (e.g., separate per region, per business unit). Customer / vendor records are tagged to one or more address books, controlling who can see them in lookups.

Deduplication

Periodic dedup process matches parties (name, address, phone). Critical to run regularly; without it, GAB silts up and one customer ends up as five parties. New customer / vendor creation should check GAB first to avoid creating duplicates.

Single shared list

Where: Organization administration > Setup > Financial reasons. One cross-company list of reason codes, with checkboxes that control which modules each code is selectable in: Ledger, Asset, Bank, Customer, Vendor. Modular activation lets a single "Audit adjustment" code be available everywhere, while a "Customer credit memo" code is restricted to AR.

Where reason codes appear

• General journal lines (mandatory or optional per journal name).
• Vendor invoice register / invoice journal / invoice approval.
• Sales orders, free-text invoices, project invoice proposals.
• Payment reversal, customer / vendor write-off.
• Fixed asset transactions (acquisition, disposal, write-down).
• Bank reconciliation adjustments.
• Tax transactions (stored on the tax record for audit).

Why centralize

Pre-Org-Admin centralization, each module had its own reason-code table. The shared Financial reasons list standardizes the catalog and ensures the same code means the same thing across modules, important for audit, SOX testing, and cross-module reporting.

Required vs. optional

Per journal name (and per module) you can mark reason code as required, blocking posting until set. Use sparingly; over-required reason codes train users to pick "Other" without thinking.

Number sequence wizard

Where: Organization administration > Number sequences > Number sequences > Generate number sequences. The wizard creates default sequences for all references that need one. Run early in setup; customize after.

Scope

• Shared: one sequence across all LEs (e.g., worker number).
• Company: per LE (e.g., sales order number).
• Fiscal calendar / period: resets each year / period (some statutory references).
• Legal entity, fiscal calendar period: combinations for granular control.

Continuous vs. non-continuous

Continuous guarantees no gaps but locks the database during sequence allocation; performance bottleneck on high-volume sequences. Non-continuous allows gaps but doesn't lock; recommended unless statutory requirement forces continuous (e.g., some EU invoice-numbering rules).

Format

Format string with prefix, segments, padding (e.g., SO-#####). Once transactions use the sequence, format changes are restricted; design carefully.

Working calendars

Where: Organization administration > Setup > Calendars > Calendars. Define working hours per day / week, holidays, exceptions. Used by master planning, production scheduling, project resource availability, transportation.

Working time templates

Reusable shift patterns (standard 8-hour day, 24x7 plant, 4-day workweek). Calendar built by applying a template across a date range.

Fiscal calendar

Different concept: defines fiscal years and periods for ledger posting. Where: General ledger > Calendars > Fiscal calendars. Multiple LEs can share one fiscal calendar.

Where consumed

• Master planning: uses calendars for lead time / due date math.
• Production: uses resource calendars for finite scheduling.
• Transportation: uses calendars for transit time.
• Project: uses worker calendars for resource availability.
• HR: calendar holidays drive leave-day calculation.

Day-one calendar setup

Build the standard working calendar with current and next year holidays before go-live. Production / planning issues are often calendar issues in disguise.

Native US Payroll

F&O ships native US Payroll: federal, state, local taxes, garnishments, benefits, multiple work-state allocation. Quarterly tax filings and W-2 generation are supported. Note: Microsoft has been steering new customers toward partner integrations (Dayforce, ADP) rather than native US Payroll; verify the strategic fit and roadmap before committing to native for a new implementation.

Other regions

For Canada, UK, EU, AU, etc., F&O does NOT process payroll natively. Standard pattern:

• Master data (worker, position, comp, leave, hours) flows from F&O HR / Time to the payroll provider via integration.
• Provider processes net pay, tax, statutory deductions.
• GL summary posts back to F&O via journal upload (DMF or Power Automate).

Payroll parameters

Where: Payroll > Setup > Parameters > Payroll parameters. Number sequences, default tax engine, holiday calendar, retro calculation rules.

Tax engine integration

US tax calculation uses an integrated provider (Vertex, Avalara payroll, or symmetry). Setup links F&O to the engine; tax rules update through the provider's content service.

Where: Payroll > Setup > Earning codes, Payroll > Setup > Deductions and contributions, Payroll > Setup > Taxes.

Earning codes

Per type: regular, overtime, bonus, commission, double-time, holiday, PTO. Each tied to a productive / non-productive flag (FLSA), tax behavior, accumulator, pay-frequency rules.

Deduction codes

Pre-tax (401k, HSA, FSA, certain medical) vs. post-tax (Roth, garnishments, charity). Deduction calculation: flat, percent, hours, formula. Limits per pay / per year / lifetime.

Benefit plans

Where: Human resources > Benefits integrates with payroll. Plan defines employer / employee cost split, eligibility, dependent rules. Open enrollment workflow assigns workers; payroll computes deductions automatically.

Tax codes & jurisdictions

Federal, state (per work state and resident state), local (city, county, school district). Multi-state allocation supports remote workers and traveling sales reps.

Worker tax setup

Form W-4 information per worker (filing status, allowances, additional withholding). State equivalents per state. Updates effective-dated.

Pay cycles & periods

Where: Payroll > Setup > Pay cycles. Cycle (weekly, biweekly, semimonthly, monthly) with multiple pay periods per year. Each period has start, end, payment, cutoff dates.

Pay run process

1. Generate earnings (from approved time entries, salaries, scheduled bonuses).
2. Calculate pay statements (gross to net, taxes, deductions, benefits).
3. Review & approve (audit reports, exception lists).
4. Issue payments (ACH file, check print) and tax disbursements.
5. Post to GL (per posting setup) and close pay period.

Pay statement

The per-worker per-period record. Reviewable, reversible (with audit) before posting; once paid, corrections require off-cycle adjustment.

Off-cycle & manual checks

For terminations, bonuses, error corrections. Run independently of regular cycle; consume same setup but use off-cycle pay run type.

Retro pay

Compensation change effective-dated to the past triggers retro calculation. F&O recalculates affected periods and surfaces the difference as a retro earning on the next pay statement.

Posting setup

Where: Payroll > Setup > Posting. Per earning, deduction, tax, benefit: which GL account is debited / credited. Department / cost center allocation drives the financial dimension on each line.

Standard payroll journal

• Salary / wage expense (debit), broken by department dimension.
• Tax expense (employer share) (debit).
• Benefit expense (employer share) (debit).
• Net pay liability / cash (credit).
• Tax liabilities (credit, paid to authorities later).
• Deduction liabilities (credit, paid to vendors / 401k provider later).

Accruals

Pay periods spanning month-end require accrual. F&O can auto-accrue based on calendar days or you can post manual accrual journals reversed in the next period.

Reconciliation

Payroll-to-GL reconciliation: pay statement totals must agree to GL postings. Run after each pay run; investigate variances before next cycle.

Quarterly tax filings (US)

941 (federal income tax + FICA), state quarterly returns, FUTA / SUTA. F&O generates the data; filing typically electronic via tax engine integration.

Year-end

• W-2 generation per worker (federal + state).
• 1099-NEC for contractor payments (overlaps with AP for non-payroll vendors).
• ACA reporting (1094 / 1095) for employers subject to ACA.
• State and local equivalents.

Year-end checklist

• Reconcile pay statement totals to GL.
• Verify worker addresses / SSNs.
• Process final adjustments (bonuses, true-ups).
• Run W-2 preview, distribute corrections, finalize.
• Roll year (close prior year, open new year, update tax tables).

Garnishments

Court-ordered deductions (child support, levy). Setup per worker with order details, max-percentage rules per CCPA, priority sequencing if multiple. Compliance-critical; errors create personal liability for the employer.

Procurement parameters

Where: Procurement and sourcing > Setup > Procurement and sourcing parameters. Drives PO defaults, change management activation, three-way match defaults, requisition / RFQ behavior, and number sequences.

Procurement category hierarchy

Where: Procurement and sourcing > Catalogs > Procurement category hierarchy. Multi-level taxonomy for what's purchased (IT > Hardware > Laptops; Office > Supplies > Paper). Categories drive default account, allowed vendors, signing limits, and reporting groupings. The single most important master-data design decision in the module.

Purchasing policies

Where: Procurement and sourcing > Setup > Policies > Purchasing policies. Per organization unit, define the allowed catalog model (open catalog, restricted to approved vendors), category access, requisition vs. PO requirements, and PO change management activation. Powerful and configurable, but easy to over-engineer.

Activation policies

Determine which policies apply to whom: per legal entity, per department, per operating unit. Allows mixed models (e.g., strict requisition policy in HQ, looser in field offices).

Vendor categorization

Vendors are linked to procurement categories via the Vendor > Procurement categories tab. Determines which vendors can be selected when a requisition / PO is in a given category, prevents accidental sourcing from unapproved vendors.

Internal catalogs

Where: Procurement and sourcing > Catalogs > Procurement catalogs. Curated list of items / categories an internal user can request via Self-service requisitions. Reduces shadow purchasing.

External catalogs (punch-out)

Punch-out catalogs send the requester to a vendor's website (Office Depot, Grainger, Amazon Business) to shop, then return the cart back into a F&O requisition. Standard cXML / OCI integration; requires per-vendor connector setup.

Vendor onboarding via Vendor Collaboration

Self-service vendor sign-up and profile maintenance, see Vendor Collaboration module.

Purchase requisitions

Where: Procurement and sourcing > Purchase requisitions > All purchase requisitions. The internal request for goods / services. Workflow approval based on amount, category, organization. On approval, automatically converted to one of: PO, RFQ, consolidated PO line on existing order.

Request for Quotation (RFQ)

Where: Procurement and sourcing > Purchasing > Requests for quotation > All requests for quotation. Send the same RFQ to multiple vendors, collect bids, score, and award. Award generates a PO automatically.

Purchase agreements

Where: Procurement and sourcing > Purchase agreements > Purchase agreements. Pre-negotiated commitment with a vendor over a period; release orders (POs) consume the commitment. Four commitment types:

• Product quantity commitment: fixed quantity of a specific product over the period.
• Product value commitment: fixed monetary value of a specific product.
• Product category value commitment: fixed monetary value within a procurement category (any product in the category).
• Value commitment: total monetary value, any product or category.

Pricing terms on a purchase agreement (price / discount on the lines) override trade agreements for the duration. Header policies control fulfillment: enforce max, fix price/discount, min/max release amount per release order. Intercompany pairs with a Sales agreement on the partner LE.

Purchase order types

• Standard PO: single-event order.
• Blanket / agreement-driven PO: against a purchase agreement.
• Planned PO: from Master planning, becomes a real PO on firming.
• Returned PO: for return-to-vendor flow.
• Subscription PO: recurring delivery, used in subscription scenarios.

PO change management

When activated, every change to an approved PO triggers re-approval workflow. Audits price increases, quantity changes, vendor swaps. Required in regulated industries; optional elsewhere.

Trade agreements (purchase prices & discounts)

Where: Procurement and sourcing > Prices and discounts > Trade agreement journals. Maintain prices and discounts via a journal posting model. Four agreement types:

• Price (purch.): per-unit purchase price.
• Line discount (purch.): per-line discount.
• Multiline discount (purch.): discount triggered by total quantity / value across lines.
• Total discount (purch.): header-level discount on the full PO.

Each row keys on Account code (Table = specific vendor / Group / All) × Item code (Table / Group / All) × effective dates × quantity break. Activate via the journal's Post action. Hierarchy of evaluation: Table beats Group beats All; specific date / quantity beats general.

Sales agreements vs. trade agreements (purchase side)

Purchase agreements (covered above) are commitments with consumed quantity / value tracking. Trade agreements are open price lists without commitment. Use trade agreements for general pricing, purchase agreements when a real volume / value commitment is negotiated.

Charges codes

Where: Procurement and sourcing > Setup > Charges > Charges code. Define each charge type (Freight, Brokerage, Customs, Handling, Restocking, Insurance fee, etc.). Per code:

• Debit type: Ledger (post to expense account), Item (allocate to inventory cost), Customer / Vendor (post to customer / vendor account).
• Credit type: mirror options for the offset.
• Posting: the GL accounts hit per debit / credit type.
• Compare PO and invoice values: for matching tolerance.

Critical: Debit = Item rolls the charge into inventory cost (raises landed cost of the line); Debit = Ledger expenses the charge directly. Choose deliberately per charge type.

Auto charges

Where: Procurement and sourcing > Setup > Charges > Auto charges. Rules that automatically apply charges to PO header or PO line based on:

• Account code: Table (specific vendor) / Group / All.
• Item code: Table / Group / All.
• Header vs. line: applied to whole PO or per-line.

Hierarchy: a Table-level rule beats Group beats All; a more specific match beats a general one. Auto charges remove the manual step of adding freight / brokerage to every PO and standardize how charges flow.

Manual charges

Outside auto charges, charges can be added manually on a PO (Header > Charges or per line, Line > Charges) for one-off costs. Same Charges-code rules apply.

PO confirmation

Vendor confirms acceptance of the order; PO status moves to Confirmed. Triggers vendor commitment on the GL if encumbrance is enabled.

Product receipt

Where: from the PO, Receive > Product receipt. For advanced WMS warehouses, receiving happens via the Warehouse Management mobile app (Purchase order receiving / License plate receiving menu items) and the product receipt posts when the load arrives at the final put-away location. Product receipt posts the inventory receipt and the purchase accrual (GRNI) liability. Note: "Product receipt" is the inbound (PO) term; "Packing slip" is the outbound (sales / inventory) term, both are current and refer to opposite sides of the inventory transaction.

Receipt registration

Lighter-touch receipt that records arrival without formally posting; useful for inspection-required items. Posting happens after inspection passes.

Three-way match

At AP invoice posting, F&O compares: PO line price + receipt quantity + invoice values. Tolerances configured per item / vendor / matching policy. Mismatches park the invoice for review. The control that catches both vendor errors and internal posting errors.

• Spend analysis workspace: spend by category, vendor, period; PO commitments vs. actual.
• Open PO commitments: backlog of unbilled receipts and unfulfilled PO lines.
• Vendor performance: on-time delivery, in-full delivery, lead time variance.
• Three-way match exception report: matching exceptions by aging.
• Power BI: for executive procurement dashboards (top vendors, categories, savings).

Where: Product information management > Products > All products and product masters > New.

Product type

• Item: physical, stocked. Most goods.
• Service: non-stocked; used in service-billing scenarios. No physical inventory.

Product subtype

• Product: a single SKU without variants.
• Product master: a parent that has variants (color, size, style, configuration).

Choosing wrong here forces a re-master later, recreate the items as the right subtype and migrate transactions. Decide based on whether the SKU has variants now or in the future.

Number sequences

Item numbers ideally come from a non-meaningful number sequence. "Smart" numbers (encoding category, color, year) seem helpful but always regret as the rules evolve.

Product dimensions

Up to four product dimensions per product master: Color, Size, Style, Configuration. Each combination becomes a variant (a Red-Large T-shirt is one variant of the T-shirt master). Custom dimensions beyond these four are not supported; use attributes for finer differentiation.

Variant generation

Variants can be generated from dimensions automatically (every combination) or manually (only the combinations actually sold). For high-dimensionality products (jewelry: 50 metals × 30 stones × 100 sizes), generating every combination produces millions of variants and breaks reporting; configure-to-order patterns are a better fit.

Dimension groups (storage and tracking)

Set per item; controls which dimensions are required at order entry, picking, costing. See Inventory Management for full discussion. Dimension groups are effectively unchangeable post-transactions, decide carefully.

Item model groups

The most consequential setup. Drives costing method, physical / financial inventory posting, allow-negative-inventory behavior. See Cost Management for full discussion.

Category hierarchies

Where: Product information management > Setup > Categories and attributes. Multiple hierarchies per purpose:

• Procurement category hierarchy: drives procurement category access, default accounts, signing limits.
• Sales category hierarchy: drives sales reporting groupings.
• Retail category hierarchy: drives navigation, assortment, and POS displays.
• Custom hierarchies: for any purpose-specific grouping.

Attributes and attribute groups

Per category: define attributes (Color name, Material, Country of origin, Voltage). Attributes are searchable, filterable, displayable on the product card. Attribute groups bundle related attributes for inheritance.

Default account setup via category

Tying category to default account is a strong best practice; lets you route revenue / COGS by category without overriding per item.

Shared vs. released

A shared product exists once across the organization (Product information management > Products > All products and product masters). To use it in a specific legal entity, release it; the released-product record (Product information management > Products > Released products) holds entity-specific fields:

• Item group (mandatory): drives inventory posting profile to GL.
• Item model group: costing method, stocked status, accruals.
• Storage / Tracking dimension groups: per-entity if not already on shared.
• Default tax groups, item sales / purchase tax groups.
• Default financial dimensions.
• Default order settings (see below).
• Sales / purchase prices, trade agreements scope.

Release process

Where: Product information management > Products > Released products > Release products, or from a shared product, Release products. Wizard: select shared product > select target legal entities > configure the per-entity defaults > release. Post-release, edits to the shared product propagate to all entities; entity-specific fields are owned per entity.

Multi-entity considerations

Decide what is global (item number, name, product dimensions) versus local (price, tax group, default warehouse). Reverse-engineering a released product to be shared across more entities is straightforward; the opposite (de-releasing) is not.

Product change management

For governed environments, F&O has a Product change cases feature that wraps changes in workflow approval, useful in regulated industries (medical devices, food).

What it is

Where: on a released product, Plan > Default order settings (or via the released-product list, Plan > Default order settings). Three FastTabs:

• Purchase: default site, warehouse, vendor, min / max / multiple / standard order quantity, lead time, stop flag.
• Sales: default site, warehouse, min / max / multiple / standard sales quantity, lead time, stop flag.
• Inventory (transfer): default site, warehouse, min / max / multiple / standard transfer quantity, transfer lead time, stop flag.

Site-specific order settings

Override defaults per site via Plan > Site specific order settings. Required when the same item ships from different sites with different lead times, vendors, or quantities. Site-specific rules win over default order settings when both apply.

Where it's consumed

• PO line creation pulls vendor / warehouse / lead time defaults.
• SO line creation pulls warehouse / lead time defaults.
• Transfer order creation pulls transfer lead time.
• Master Planning uses lead times and min / max / multiple to size planned orders.
• Sales agreement, purchase agreement, RFQ, and requisition lines all default through these settings.

Stop flag

Stops new purchase / sales / transfer orders for the item, useful for end-of-life, recall, or quality hold. Different from item Hold (which blocks transactions wholesale); stop is per direction (purchase only, sales only).

Item coverage (planning override)

Where: from the released product, Plan > Item coverage. Per warehouse, override coverage group, lead time, min / max for planning purposes only. Common pattern: Default order settings hold operational defaults; Item coverage adds warehouse-specific planning behavior.

• Smart-number IDs. Always regretted; use neutral number sequences and let attributes carry meaning.
• Variants exploded as separate items. 500 SKUs that should be one product master with 500 variants. Inventory and reporting break.
• Wrong item model group. Switching costing methodology after go-live is the most painful re-master in F&O.
• Wrong dimension groups. Adding a tracking dimension (batch, serial) post-launch is migration-grade work.
• Categories as flat list. Without category hierarchy, default accounts, procurement controls, and reporting all degrade.
• One category hierarchy for all purposes. Procurement, sales, retail have different needs; use multiple hierarchies.

Production type per item

Where: released product, Engineer > Production type. Options: None, BOM (discrete production order), Formula (batch order), Planning item (phantom for planning only), Co-product / By-product (linked to a planning item).

Production control parameters

Where: Production control > Setup > Production control parameters. Defines defaults: automatic update on report-as-finished, automatic BOM consumption (flushing principle), backflushing, route consumption, ledger posting timing.

Posting profiles & ledger integration

Where: Production control > Setup > Posting. Defines GL accounts for WIP issue, WIP receipt, picking list, report-as-finished, and end. Tied to inventory item groups (or item-level overrides). Errors here are the most common cause of inventory-to-GL reconciliation issues.

Production status flow

Created → Estimated → Scheduled → Released → Started → Reported as finished → Ended. Each transition can post inventory and ledger journals depending on parameters. Ended is irreversible; it triggers final variance posting.

BOMs and BOM versions

A BOM is the parts list; a BOM version ties it to a finished item, with from/to dates and from/to quantities (for engineering-change control). Multiple active versions allow phased cutover.

Formulas (process)

Equivalent of BOM for batch orders. Formula lines support scalable ingredients (scale with batch size), fixed ingredients (constant per batch), step consumption (tiered by batch size). Formulas also handle co-products and by-products.

Routes and route versions

A route is the sequence of operations; a route version ties it to a finished item. Route operations reference operations resources (machines, work cells, labor pools). Setup time, run time, queue time per operation drive scheduling.

Resources and resource groups

Where: Production control > Setup > Resources > Resources. Resource types: machine, human resource, tool, location, vendor, facility. Resource capabilities (skills) match against operation requirements during scheduling.

BOM calculation

Standard cost roll-up uses the BOM and route to compute manufactured cost. Run periodically; results feed cost version (planned cost) or activated standard. Required for standard-cost manufacturers.

Operations scheduling

Schedules at the operation level (one start / end date per operation). Faster, less granular. Used for capacity-rough-cut planning.

Job scheduling

Schedules at the job level (setup / process / queue / transport jobs per operation). Slower, more granular, supports finite resource capacity. Used for execution-level dispatch.

Forward vs. backward scheduling

Forward: from start date forward; tells you when production will finish. Backward: from due date backward; tells you when to start. Master Planning typically schedules backward from the demand date.

Finite vs. infinite capacity

Infinite ignores resource conflicts (assume capacity); finite respects existing reservations. Finite is mandatory for accurate dispatch but increases scheduling time.

Estimation

Calculates standard cost based on BOM / formula and route. Sets the baseline for variance reporting. No GL impact.

Release

Frees inventory reservations, prints work documents (production schedule, picking list, route card / job card). Optional ledger posting depending on parameters.

Start

Triggers automatic consumption (if backflushing enabled) of materials and resources. Posts the picking list and route card journals. Inventory posts WIP cost > raw material credit; production resources post WIP labor.

Report as finished (RAF)

Records produced quantity to inventory. Posts finished goods debit > WIP credit at standard cost. Can be partial; allows multiple RAF events per order.

End

Final closing of the order: variances posted (quantity, price, substitution, lot size), order locked. Sequence-dependent; if ended out of order with related orders (multi-level BOMs), variances may be miscalculated. Tools: End production order via Periodic.

Production journals

Picking list (raw material consumption), route card (operation time per route step), job card (operation time per job), report-as-finished (output). Each can be edited before posting.

Batch order specifics

Triggered when production type is Formula. Lifecycle similar to discrete, but supports batch attributes (potency, density), shelf-life dates (expiration assigned at RAF), batch disposition codes.

Co-products and by-products

Co-product: intentional secondary output, cost allocated based on weight / volume / value. By-product: incidental output, cost-burden or cost-credit. Defined in the formula on the planning item.

Catch weight

For variable-weight items (meat, fish, chemicals): formula nominal weight, actual weight captured at RAF. Inventory tracks both.

Process-specific reporting

Yield reports, batch genealogy (forward / backward trace), regulatory reporting (FDA 21 CFR Part 11, EU REACH).

Kanban rules

Where: Production control > Setup > Lean manufacturing > Kanban rules. Defines a replenishment loop: trigger (demand), production activity (work to perform), quantities, fixed kanbans circulating.

Kanban types

• Manufacturing kanban: triggers production at a work cell.
• Withdrawal kanban: triggers movement from one location to another.
• Sales (event) kanban: triggered on demand (sales order, transfer, etc.) for non-stocked items.

Kanban board

Visual queue at the work cell showing pending kanbans, in-progress, completed. Workers update status from the board. Replaces the traditional production schedule for lean cells.

When lean is the right choice

High-volume, repetitive production; stable demand; short cycle times. Lean excels here. For low-volume / high-mix or engineer-to-order, traditional production orders fit better.

Production floor execution (PFE)

Browser-based shop-floor app shipped with F&O. Workers clock in / out of jobs, report progress, capture quality, view drawings. Replaces older Job Card terminal.

Manufacturing Execution System (MES) integration

For complex shop floors, integrate with a dedicated MES (Critical Manufacturing, Plex, Aegis FactoryLogix). Standard interfaces: production order release out, job time / quantity in. Often via Azure Service Bus or DMF recurring integrations.

Shop floor barcode & mobile

Combine PFE with barcode scanners or mobile devices for hands-free reporting. Common pattern: badge scan to clock in, BOM material scan to confirm consumption, finished-goods barcode at RAF.

WIP accounting

Picking list and route card post to WIP accounts. RAF reverses WIP and posts to finished goods. End calculates final variances. Ideal: WIP balance at month-end matches the WIP report; reality: timing differences require reconciliation.

Production variances (standard cost)

• Quantity variance: actual material qty consumed vs. BOM standard.
• Price variance: actual material cost vs. standard cost.
• Substitution variance: different item used vs. BOM specified.
• Lot size variance: setup / fixed costs spread over actual qty vs. standard lot size.
• Routing variance: actual operation time vs. routed time.

Reconciliation & reporting

Periodic: Cost management > Periodic tasks > Inventory close (closes the costing layer). Reports: Production variance, WIP report, Production posting. Aim for monthly close discipline; reopening prior periods to fix production orders is painful.

• End production order discipline: orders left at RAF (not Ended) leave variances unposted; periodic end-production routine is mandatory.
• BOM and route version dates: mis-set from / to dates cause "no active BOM" errors mid-period; always check effective dates on cutover.
• Backflushing risk: if BOM is wrong, backflushing posts wrong consumption silently; reconciliation only catches it at month-end.
• Resource calendar accuracy: scheduling assumes calendars are correct; holidays / shift patterns missing cause infeasible schedules.
• Multi-level BOMs and order linking: sub-orders linked to a parent must be ended in correct sequence, or top-level cost rolls up wrong.
• Process vs. discrete decision: teams often pick "BOM" because it's simpler, then hit the wall when shelf-life or co-product features are needed; choose based on actual process, not familiarity.

Project types

Six built-in types, each with distinct accounting:

• Time: internal time-tracking only, no billing or revenue.
• Time and material (T&M): external, billed at cost / rate; revenue recognized as costs are incurred.
• Fixed price: external, billed per milestones or invoice schedule; revenue recognized via POC (cost-to-cost) or completed contract.
• Investment: internal capital project; cost accumulates as CIP, capitalized to FA on placed-in-service.
• Cost project: internal cost capture, P&L expense with no balance-sheet implication.
• Internal: non-billable internal work tracking.

Project groups

Where: Project management and accounting > Setup > Posting > Project groups. Drives default ledger posting (which accounts the project transactions hit), revenue recognition method, line property defaults, and accruals behavior.

Project categories and shared categories

Two-level structure: Shared categories are cross-company; Project categories are per-company refinements. Each project transaction (hour / expense / item / fee) is classified by category, which drives the GL account hit and the reporting roll-up.

Posting setup

The most underestimated configuration in PMA. Project ledger posting (under Project groups) ties transaction types and categories to specific GL accounts: cost accounts, WIP cost, accrued revenue, billed revenue, deferred revenue. Get this wrong and project margins are reported wrong.

Where: Project management and accounting > Projects > All projects.

Project hierarchy

Project > Sub-project (one level deep, useful for splitting major phases) > Activities (the WBS structure, multi-level). The WBS is where work is planned and tracked; activities can have hours, expenses, items consumed against them.

Project budgets vs. forecasts

• Project budget: top-down cost / revenue plan for the project, with workflow approval. Used for budget vs. actual comparison.
• Project forecast: bottom-up estimate of remaining work, more granular and updateable. Drives revenue recognition on POC projects.

Both are important; budget for executive reporting, forecast for revenue recognition accuracy.

Line property

Per category / project, drives whether costs are chargeable (billable to customer), non-chargeable (absorbed), or capitalized (CIP) by default. Can be overridden per transaction.

Project contracts (external projects)

For external projects, a Project contract holds customer info, billing terms, retention percentage, hour rates / fee schedule. Multiple projects can share a contract for batch billing.

Where: Project management and accounting > Project journals (Hour, Expense, Item, Fee, On-account).

Hour transactions

Two paths: Hour journal (back-office entry) or Timesheet (worker self-service entry, with manager approval workflow). Approved timesheets create hour transactions on the project. F&O timesheet, Project Operations time entry, or third-party (Replicon, Tempo) all flow back to PMA hour transactions ultimately.

Expense transactions

From Expense Management with project distribution. Expense report approved > posts to AP > project transaction created with the matched expense category.

Item transactions

Materials consumed on the project: from inventory (Item journal > Project), from a PO directly to project (PO line with project), or from an inventory transfer. Posts to project material cost.

Fee transactions

Non-cost revenue events for fixed-price projects: milestone fee at delivery, retainer fee monthly. Generates invoice without underlying time/expense.

On-account transactions

Customer advance against future work: invoice issued upfront, sits as deferred revenue, consumed against subsequent fee / hour transactions.

T&M revenue

Recognized as costs are incurred (cost-based). The hour / expense / item transaction posts the cost and accrues revenue at the billable rate. Invoice proposal turns the accrued revenue into billed revenue.

Fixed-price revenue methods

• Percentage of completion (POC, cost-to-cost): revenue recognized as actual cost / forecast cost ratio. Most common for long-running projects.
• Completed contract: all revenue recognized at project completion. Used for short or risky projects.
• Sales value: recognize revenue based on completed milestones rather than cost ratio.
• No WIP: simple recognition without WIP accruals.

Estimate process

Where: Project management and accounting > Periodic > Estimates > Estimate. Periodic process that calculates POC, books WIP / accrued revenue journals, reverses prior estimates. Run monthly (or per close cadence). The accuracy of revenue recognition depends on the project forecast being current; train PMs to update the forecast before estimate runs.

ASC 606 / IFRS 15 considerations

Both standards converge on the 5-step revenue model. F&O's flexibility (multiple revenue methods, contract structures) supports compliance, but the policy decisions (when does control transfer, how are performance obligations identified) are accounting-policy decisions, not configuration choices.

Invoice proposal

Where: on a project contract or project, Manage > Invoice proposal > Create. Generates draft invoice from billable transactions (hours, expenses, items, fees, on-account) since the last invoice. Review, adjust, post.

Billing rules

Where: on the project contract. Configurable rules for what to bill: chargeable hours, fees per milestone, progress billing for fixed-price, time-and-material billing per period.

Customer retention

For construction or long-running projects with retention clauses, configure retention percentage per project / contract. F&O withholds the percentage from each invoice and releases it at project completion.

Multi-currency project billing

Project transactions can be in one currency, customer billing in another, with FX revaluation on retained / open project balances.

Eliminate WIP

For Investment projects ready for capitalization: the Eliminate routine moves CIP to FA cost. Required step before the project can be closed.

Set project end date

Once all work is complete and final billing posted, set the project end date to lock further posting. Critical for revenue recognition on completed contract projects.

Project close checklist

• All hour / expense / item transactions posted.
• Final invoice posted.
• Estimate run for the final period; WIP balance zero (or moved to capital, deferred, etc. per project type).
• Retention released if applicable.
• Project status moved to Finished, then Closed.

Project Operations integration

For services firms using Project Operations on top of PMA: opportunity, contract, project plan, resource booking, time entry all happen in the Dataverse-based front-end; financial transactions (estimate, invoice, revenue recognition) flow into F&O PMA via dual-write. Ensure the integration is healthy at each close, drift between systems is the most common project-financials reconciliation issue.

Rebate management module (modern)

Where: Rebate management. Modern, declarative module supporting tiered rebate programs, customer / vendor symmetric, with accruals, claims, settlement workflow.

Trade allowance management (legacy / still relevant)

Older module focused on customer trade promotions: lump-sum funds, off-invoice promotions, performance-based allowances. Used by CPG companies for retailer trade spend. Continues to ship; choose modern Rebate management for new implementations unless trade-allowance-specific features are required.

Rebate parameters

Number sequences, default GL accounts for accrued rebate (asset for vendor side, liability for customer side), default rebate accrual frequency, claim approval workflow.

Rebate program type

Volume-based (qty thresholds), value-based ($ thresholds), tier-based (escalating rates), retroactive (rate applied to all units once threshold hit) vs. forward (rate from threshold onward).

Where: Rebate management > Rebate program agreements.

Rebate program / agreement

Header holds: counterparty (customer or vendor), effective dates, currency, accrual frequency, settlement method. Lines define eligible items / categories and rate structures.

Eligibility

Customer / vendor scope: single party, customer group, or all. Item / category scope: specific items, item group, or category.

Rate structures

• Flat rate: 2% of invoiced value, on every transaction.
• Tiered: 1% < 1,000 units, 2% < 5,000, 3% above. Retro or forward.
• Lump sum: $50,000 once threshold hit.

Effective dates & periods

Programs run from / to dates, with cumulative tracking inside. Year-over-year programs typically reset annually but rebate periods can span multiple calendar years.

Accrual on invoice

Sales (or purchase) invoice posts and the rebate engine evaluates: does this transaction qualify under any active program? If yes, accrual journal posts: rebate expense (debit) / accrued rebate liability (credit) for customer rebates. Vice versa for vendor rebates: receivable / income.

Recalculation

For tiered or threshold programs, the cumulative position can change. Recalc job re-evaluates open programs, books the catch-up adjustment for newly-crossed tiers (especially retro tiers).

Period close

End-of-period: ensure all in-flight invoices accrued; review accrual balance vs. expected; investigate variances. Close the rebate period to lock further posting.

GL impact (customer rebate side)

• Sales invoice: AR debit, revenue credit (gross).
• Rebate accrual: rebate expense (contra-revenue) debit, accrued rebate liability credit.
• Settlement (credit memo issued): accrued rebate liability debit, AR credit.

Claim creation

At settlement event (period end, threshold reached, customer claim received), generate a settlement claim. Claim aggregates accrued amounts per program / counterparty / period.

Settlement methods

• Credit memo (customer rebate): issue AR credit memo applied against customer's open balance.
• Check / payment (customer rebate): issue AP-like payment to customer.
• Vendor invoice (vendor rebate): create a debit memo / invoice receivable from vendor.
• Offset against invoices (vendor rebate): deduct from next vendor payment.

Approval workflow

Claims typically route to finance for approval (validates against program, accrual matches expectation). Approved claim posts the settlement; accrual liability cleared.

Customer self-claim

Some programs let customer submit a claim for what they think they earned; F&O reconciles against system-calculated accrual; variances investigated.

• Accrued rebate liability: open balance per program / counterparty; the rebate-related liability on the balance sheet.
• Settled vs. open: aging of unclaimed / unsettled rebate, identifies stale programs to investigate.
• Customer / vendor rebate analysis: rebates earned / paid per counterparty, year-over-year, identifies most expensive programs and most rebated customers.
• Margin impact: revenue net of rebate vs. gross revenue, the true margin view.
• Effectiveness: did the program drive incremental volume? Compare pre- and post-program purchase patterns.

Audit trail

Each accrual / recalc / settlement journal references the source program and transaction. SOX-relevant for the rebate process; document the calculation methodology.

Headquarters (HQ)

F&O instance: master data (products, prices, customers), back-office (replenishment, financials), reporting. The system of record.

Commerce Scale Unit (CSU)

Cloud-hosted regional scale unit (Azure microservice). Hosts the Retail Server (transactional API for POS) and channel database. Stores connect here for real-time lookups; HQ syncs to CSU asynchronously.

Channel database

Per-CSU regional copy of channel-relevant data: products, prices, customers, employees, settings. Decouples store operations from HQ availability. Bidirectional CDX (Commerce Data Exchange) handles the sync.

POS clients

Modern POS (MPOS): Windows desktop / tablet client, supports offline mode. Cloud POS: browser-based, always online. Both share configuration. Store Commerce app (newer unified client) is replacing both.

E-commerce

Microsoft-hosted B2C / B2B storefront platform with module library (header, hero, PLP, PDP, cart, checkout). Headless option exposes APIs for fully custom front-ends.

Where: Retail and Commerce > Channels > Stores > All stores (and Online stores, Call centers).

Channel types

• Retail store: physical store with terminals.
• Online store: e-commerce channel.
• Call center: agent-driven order entry (catalog companies, B2B reorders).

Stores, terminals, registers

Store > Terminal > Register hierarchy. Terminal binds to a hardware profile (cash drawer, scanner, printer). Register holds the running shift / drawer balance.

Profiles

• Functionality profile: POS behavior (return reasons, password complexity, blind close).
• Hardware profile: connected peripherals.
• Visual profile: POS branding, themes.
• Offline profile: what data MPOS holds for offline operation.

Distribution schedule (CDX)

Job-based sync: P-jobs push HQ > channel; A-jobs pull channel > HQ. Schedules per job (real-time vs. batched). Tuning these is one of the harder operational areas.

Retail product release

Products released via category hierarchy (Commerce category) with channel-relevant attributes (online description, image, SEO). Variants (color / size) handled via product master.

Assortments

Define which products are sellable in which channels. An assortment is a set of categories or specific items, effective-dated, scoped to channels / orgs. Without assortment assignment, product won't appear at POS.

Navigation hierarchy

Per channel: visual category tree shown in POS / e-commerce. Independent of internal procurement category tree.

Catalogs (call center)

Catalog defines effective dates, eligible customers, products, prices, source codes for response tracking. Mailings = a catalog drop.

Attributes & specs

Product attributes (color family, brand, target gender) drive faceted search on the e-commerce side.

Price groups

Group customers / channels for differentiated pricing. Wholesale vs. retail; member vs. non-member.

Trade agreements

Standard F&O trade agreements (price / line discount / multiline discount / total discount) flow through to channel pricing.

Retail discounts

• Quantity discount: buy 3, get 10% off.
• Threshold discount: spend $100, get $20 off.
• Mix & match: any 3 from set X for $25.
• Coupon-driven: code-based, per-customer or open.
• Best price / compounded: apply best, or stack with priority.

Affiliations & loyalty

Affiliation = membership tag (employee, AAA member). Loyalty programs award points per spend, redeemable for discounts. Tier-based programs supported.

Pricing engine

Calculation order: trade agreement price > manual override > line discount > multiline discount > total discount. Modern enhancements include Discount Concurrency Control for complex stacking.

POS layouts & screen designer

Per-functionality profile, design transaction screen with action buttons (item lookup, add customer, return, suspend). Screen designer is drag-drop; mobile / tablet / desktop variants.

Operations

Retail "operations" are pre-defined actions (print receipt, open cash drawer, no-sale, payment, return). Layouts assign operations to buttons.

Offline mode

MPOS continues operating when channel database is unreachable: caches products, prices, customers per offline profile. Sales queued, sync when online. Critical for store reliability; tune what data is offline-capable.

Payment connectors

Adyen and Stripe certified out of box. Each store / register pairs to a payment terminal; tender types map to GL accounts.

Inventory lookup

POS can query channel database (offline-capable) or call HQ for real-time on-hand across stores. Cross-store availability supports save-the-sale workflows.

Click-and-collect / BOPIS

Customer orders online, picks up in store. Order routes to selected store; store associate picks; customer receives notification. Status tracked from web checkout through pickup.

Ship-from-store

Online order fulfilled from a store rather than DC, optimized for proximity / inventory balance. Store associate picks and ships using the parcel carrier integration.

Customer order in store

Out-of-stock at the store but available elsewhere: order in POS > ship to customer. Crosses channel boundary in one transaction.

Distributed Order Management (DOM)

Rule-based engine that picks the optimal fulfillment location (store vs. DC) per order line based on inventory, cost, distance, store performance.

Statement posting

End-of-day per store / shift: close shift > calculate statement > post to GL / AR. Statement aggregates the day's transactions into journal lines.

Trickle feed (modernized)

Modern alternative to traditional batch statements: transactions post to HQ near-real-time, eliminating the daily statement bottleneck. Recommended for most new implementations.

Reconciliation

Cash declaration vs. expected; tender variance per type. Common issues: payment timing differences (Adyen settlements lag), tax rounding deltas, gift-card liability tracking.

Returns & exchanges

POS supports returns with original-receipt lookup, or blind returns (with reason / approval). Cross-channel returns (bought online, returned at store) supported with proper channel posting setup.

• Don't scope it as "another module": Commerce is a multi-month dedicated workstream with infrastructure (CSU), payment certification, hardware integration, training.
• POS goes live last: back-office, master data, pricing must stabilize first; train and pilot in test stores before full rollout.
• Offline mode discipline: what data is offline-capable defines store resilience; test offline scenarios in UAT.
• CDX troubleshooting skills: teams need a CDX expert; sync issues are a top operational risk.
• Loyalty design upfront: changing loyalty program rules post-launch has customer trust implications; design carefully.
• E-commerce scope: using Microsoft's e-commerce platform is faster but less flexible than headless + custom; pick early.

Sales and marketing parameters

Where: Sales and marketing > Setup > Sales and marketing parameters. Number sequences (lead, opportunity, quotation, campaign), default sales taxes, default delivery terms, defaults for quotation expiration.

Business relations vs. customer

A business relation is a prospect (party + contact info, no AR record). When the deal closes, the business relation is converted to a customer. Until then, the company can be in your pipeline without polluting the AR ledger.

Sales unit hierarchy

Optional sales-team structure (units & teams) for territory ownership and quota tracking. Linked to workers; opportunities are assigned to a sales unit / responsible worker.

Activity types

Phone call, meeting, task, e-mail, document. Activities log under leads, opportunities, customers; create the contact-history audit trail.

Where: Sales and marketing > Leads > All leads and Sales and marketing > Opportunities > All opportunities.

Lead

An unqualified prospect: came from a campaign, web form, trade show. Captures contact info, source, owner. Lifecycle: new > contacted > qualified > (converted to opportunity, or disqualified).

Opportunity

A qualified deal in progress: estimated revenue, expected close, sales stage, probability. Stages configurable per sales process. Pipeline view rolls opportunities by stage and probability.

Conversion to quotation / sales order

Opportunity won > create a sales quotation (with proposed lines, prices, terms) > customer accepts > convert to sales order in Sales & AR. Smooth path; the same module continues into fulfillment.

Stages and probability

Customizable stage sequence (Prospecting, Qualifying, Proposing, Negotiating, Closed-won / Closed-lost) with a default probability per stage. Drives weighted pipeline = sum(opportunity revenue * probability).

Where: Sales and marketing > Campaigns > All campaigns.

Campaigns

Marketing initiative wrapper. Includes target group, communication type (e-mail, telemarketing, direct mail), budget, expected response. Activities and leads can be linked back to a campaign for ROI tracking.

Target groups

Query-based audience definition: customers / prospects matching criteria (industry, region, last purchase date). Refresh dynamically.

Telemarketing

Call-list with scripts, dispositions, follow-up activity creation. Light-weight; serious telemarketing operations use dedicated tools (Genesys, Five9) and integrate via Power Platform.

Limitations

The campaign / marketing capabilities are basic. For modern marketing automation (e-mail journeys, scoring, ABM), Dynamics 365 Customer Insights - Journeys (formerly Marketing) is the right tool, integrated via Dataverse.

Sales quotation

Where: Sales and marketing > Sales quotations > All quotations. Header: customer / prospect, expiration, validity. Lines: items, quantities, prices, deliveries. Generates a quotation document for customer signature.

Quotation versions

Each amendment captured as a new version with audit history. Revisions can be sent during negotiation.

Conversion

Accepted > Generate sales order. Quotation status updated to confirmed; the new sales order references back. Lost quotations are flagged with reason codes for win/loss analysis.

Trade agreements link

Quotation pricing pulls from trade agreements (price / discount journals) and sales agreements when applicable, ensuring consistency with the eventual order.

Trade agreements (sales prices & discounts)

Where: Sales and marketing > Prices and discounts > Trade agreement journals. Sales-side equivalent of the procurement trade agreements. Four agreement types:

• Price (sales): per-unit sales price.
• Line discount (sales): per-line discount.
• Multiline discount (sales): discount triggered by total quantity / value across lines.
• Total discount (sales): header-level discount on the full SO.

Each row keys on Account code (Table = specific customer / Group / All) × Item code (Table / Group / All) × effective dates × quantity break. Activated via the journal's Post action; only posted journal lines drive runtime pricing. Best-price logic: Table beats Group beats All; specific date / quantity break beats general.

Unified Pricing Management (UPM)

Microsoft is gradually superseding classic trade agreements with Unified Pricing Management under Pricing management. UPM uses price component codes, structured price models, and concurrence rules (compounding / best-price selection) for richer scenarios. New implementations should evaluate UPM; classic trade agreements remain supported and continue to work.

Sales agreements

Where: Sales and marketing > Sales agreements > Sales agreements. Long-term commitment for a customer to buy. Same four commitment types as the purchase side:

• Product quantity commitment: fixed quantity of a specific product.
• Product value commitment: fixed monetary value of a specific product.
• Product category value commitment: fixed monetary value within a sales category.
• Value commitment: total monetary value, any product / category.

Pricing terms on the agreement override trade agreements for the duration. Header policies: enforce max, fix price/discount, min/max release amount per release sales order. Release orders consume the commitment; reporting tracks consumption vs. remaining.

Trade vs. sales agreement, deciding

Use trade agreements for ongoing price lists with no commitment; use sales agreements when there is an actual signed commitment with volume / value tracking. Both can coexist; sales agreement pricing wins when both apply.

When to use F&O Sales & Marketing

Small / mid sales teams; transactional pipelines; minimal need for marketing automation; want one system. Avoids the cost and complexity of a separate CRM.

When to use Dynamics 365 Sales (CE / Dataverse)

Larger pipelines, complex stages, account-based selling, advanced forecasting, integration with LinkedIn Sales Navigator, opportunity insights, marketing automation. The standard pattern at enterprise scale.

Dual-write integration

Dual-write synchronizes accounts, contacts, products, opportunities, quotations between CE Sales and F&O in near real-time. Sales reps work in Sales; AR / fulfillment teams work in F&O; both see the same data.

Project Operations bridge

For services firms, Project Operations (Dataverse-based) sits on top of CE for opportunity-to-resource-plan, with the project / time / billing back in F&O Project Management and Accounting. Dual-write maps it together.

Data ownership decision

Master data (customer, product) typically owned by F&O when both modules exist; activities / opportunities owned by CE. Dual-write maps must reflect that ownership cleanly to avoid update conflicts.

Service management parameters

Where: Service management > Setup > Service management parameters. Number sequences, default project type for service orders (typically Time and material), default activity types, and the integration toggle to project posting.

Stages

Service order lifecycle stages (Created, Assigned, In progress, Completed, Posted, Closed). Customizable per business need. Stage transitions can require workflow / signoff.

Service relation to projects

Each service order is backed by a project (T&M typically). Time, expense, item postings on the service order flow to the project; billing uses project invoice proposal.

Reason codes & priority

Reason codes drive analytics (why was service requested, why escalated). Priority drives scheduling order on the dispatch board.

Where: Service management > Setup > Service objects > Service objects and Service management > Setup > Service templates.

Service objects

The thing being serviced (a piece of equipment at a customer site, a vehicle, an installed system). Identified by serial number when applicable. Carries history of past service.

Service object groups

Categorize objects (HVAC unit, elevator, conveyor) for templating and reporting.

Service templates

Pre-defined work scope per object group: standard tasks, expected duration, required parts. Applied when creating a service order to pre-populate lines.

Service BOMs

Parts list typically required for a service. Drives material reservation and replenishment for service trucks / depots.

Skills & resources

Service workers tagged with skills (HVAC certified, electrical license). Dispatch matches required skills to available workers.

Where: Service management > Service agreements > Service agreements and Service management > Service orders > Service orders.

Service agreement

Long-running contract between you and customer (annual PM, warranty support). Defines scheduled visits, included items / labor, prepaid hours, billing cadence. Generates service orders per scheduled visit.

Service order

A specific job: customer, object, scope, scheduled date / time, assigned worker, lines (labor, parts, expenses, fees). Created from agreement, from a customer call (ad-hoc), or from a corrective action linked to a complaint.

Dispatch board

Visual scheduling: workers along one axis, time along the other; drag service orders into slots. Considers worker skills, location, route. F&O's dispatch board is functional but less sophisticated than D365 Field Service's resource scheduler.

Service order lifecycle

1. Created > Assigned to worker.
2. Worker arrives, captures time / parts / notes.
3. Marked complete; customer signoff.
4. Posted: time / parts post to project; project invoice proposal generates customer invoice.
5. Closed.

Subcontracting

Service work farmed to a partner: PO to subcontractor links to the service order; cost flows through and is billed to customer (or absorbed under agreement).

RMA (Returns Management)

Customer returns failed item: RMA created > replacement shipped > failed item received and inspected > disposition (repair, scrap, replace under warranty). Cross-references to original sales order.

Repair lines

For depot repair: failed item received, repair work order created, labor / parts logged, repaired unit returned to customer. Tracks repair cost vs. replacement decision.

Loaner tracking

Loaner unit shipped while customer's unit is in repair; tracked as a temporary asset transfer with return expectation.

Warranty determination

Service object carries warranty terms (start, duration). Service order line auto-flags warranty: covered (no charge to customer), or out-of-warranty (billable). Avoids manual lookup mistakes.

Project-backed billing

Service order time / expense / item posts as project transactions; billing via standard project invoice proposal. Supports multi-currency, retention, milestone billing.

Free-text invoice (alternative)

For fixed-price service charges without underlying project tracking, post a free-text invoice. Simpler but loses the cost-vs.-revenue visibility per service order.

Prepaid hours from agreement

Service agreement with prepaid block (e.g., 100 hours per year). Each service order draws hours; billing only when block is exhausted or per agreement terms.

Recurring invoicing

Maintenance contracts often bill monthly / quarterly regardless of activity. Subscription Billing module is the modern path for that pattern; Service Management agreements handle simpler recurrences directly.

Service Management (F&O) when

• Customer-facing field or depot service is moderate-volume.
• Billing tied to projects already managed in F&O.
• Don't need mobile-first technician app or AI scheduling.

Asset Management when

• Maintaining your own assets (plant equipment, fleet).
• Internal work orders, no customer billing.
• Preventive maintenance schedules with full asset history.

Dynamics 365 Field Service when

• Large-scale field operations (50+ technicians, complex routing).
• Customer self-service, IoT-connected device telemetry.
• Deep mobile experience with offline, photos, signature capture.
• Sophisticated scheduling (Resource Scheduling Optimization).

Common mistake

Picking F&O Service Management to save license cost, then over-extending it for an enterprise field-service operation. Field Service was purpose-built; for any non-trivial service business, evaluate it seriously.

Three sub-capabilities

Subscription Billing groups three feature areas, each with its own parameters:

• Billing schedules: recurring invoice generation.
• Revenue and expense deferrals: period-spread of revenue / expense per ASC 606 rules.
• Multiple element arrangements (MEA): contracts with bundled performance obligations needing standalone-selling-price allocation.

Module parameters

Where: Subscription billing > Setup > Parameters. Number sequences, default templates per billing type, default revenue accounts for deferral, milestone-billing default behavior.

Pricing engine

Subscription pricing supports tiered (per-user step pricing), volume-based (rate per unit at total volume), per-event, flat fee, percent of base, prorated. Engine evaluates per billing cycle.

Templates

Pre-defined billing schedule templates (annual prepaid, monthly recurring, quarterly anniversary). Speeds setup; standardizes patterns across customers.

Where: Subscription billing > Billing schedules > All billing schedules.

Billing schedule (header)

The contract: customer, currency, start / end dates, status, billing cycle (monthly / quarterly / annual), invoice timing (in-advance vs. in-arrears), proration policy, escalators (annual % increase).

Billing schedule lines

Per item / service in the contract: item, qty, rate, billing frequency, period start / end, optional revenue-recognition method per line. Each line generates its own invoice line each cycle.

Evergreen vs. fixed-term

• Evergreen: auto-renews until cancelled. Common for SaaS month-to-month or annual auto-renewals.
• Fixed-term: defined end date; no further billing after.

Co-terminus dates

For amendments: add-on lines aligned to existing contract end-date so all bills synchronize. Engine prorates first-period charges.

Linkage to sales / customer

Billing schedule references customer; can link to a sales order or sales agreement for pricing source. AR posts invoice via standard customer flow.

Generate billing schedule lines

Periodic job: Subscription billing > Periodic > Generate billing schedule lines. Walks active schedules, calculates due-this-period billing lines, queues for invoicing.

Invoice generation

Generated lines roll into customer invoices (one invoice per customer per billing cycle, configurable). Posts to AR like any other free-text or sales invoice.

Milestone billing

For event-driven billing (delivery completed, signoff received): milestone billing schedules trigger billing on date or event reached, not a fixed cycle. Useful for project / construction / professional-services revenue.

Usage-based billing

Bring usage data (API calls, storage GB, transactions) via integration; engine applies tiered pricing per period; bills the consumption charge.

Amendments & mid-cycle changes

Quantity increase / decrease, item add / remove, rate change, early termination. Each amendment recalculates affected periods (proration), generates catch-up or credit invoice as needed.

Revenue / expense deferral

For prepaid annual contracts: invoice posts to AR / Deferred revenue (liability) initially; recognition spreads cash / accrual basis over service period. F&O auto-creates deferral schedule from the billing line and posts month-end recognition journals.

Recognition methods

• Straight line: equal monthly recognition over service period.
• Daily proration: proportional to days in period.
• Custom event-based: recognition triggered by external event (delivery, milestone).

Multiple Element Arrangements (MEA)

Contract with multiple performance obligations (software license + implementation + support) requires standalone selling price (SSP) allocation under ASC 606. Module supports SSP master, allocation calculation (residual, relative-fair-value), and per-obligation deferral. Removes the spreadsheet-based allocation that finance teams used to do manually.

5-step ASC 606 / IFRS 15 model

Standards align: identify contract, identify obligations, determine transaction price, allocate to obligations, recognize as obligations satisfied. Subscription Billing structures the data to support each step; the policy decisions (when does control transfer, what's a distinct obligation) remain accounting decisions.

Adjustment scenarios

Cancellation: remaining deferred revenue may need acceleration or refund. Amendment: SSP re-allocation if contract value changes. Module supports both with audit trail.

Annual Recurring Revenue (ARR)

Sum of annualized active subscription value. Standard SaaS metric; module aggregates across active billing schedules, segmented by customer / product / period.

MRR & movement

Monthly recurring revenue with movement detail: new ARR (new customers), expansion ARR (upsells), contraction ARR (downsells), churn ARR (cancellations). The retention story.

Deferred revenue waterfall

Beginning balance plus new bookings minus recognition equals ending balance, by period and contract. Audit-critical for ASC 606 disclosures.

Backlog

Unbilled committed revenue (signed contracts not yet invoiced). The forward-looking revenue indicator.

Integration with financial reports

Deferred revenue accounts feed financial statements directly. Subscription Billing reports drill down to the contract / line level for audit support.

• Replace, don't supplement: if currently on legacy Recurring Contract Billing or third-party (BillingPlatform, Zuora), plan migration path; running parallel is hard.
• Master billing setup: data quality matters; existing customer / item / pricing master must be clean before subscription overlay.
• SSP discipline: for MEA, the standalone selling price master is core; require finance ownership of SSP updates as products / pricing change.
• Period-end discipline: revenue deferral close requires the deferral schedule processing job to run before close; build into close calendar.
• Reconciliation point: deferred revenue balance per Subscription Billing reports must equal GL deferred revenue account; reconcile monthly.
• Customer-friendly invoices: subscription invoices need clear period coverage and pro-ration explanation; design invoice format with customer-facing clarity in mind.

Where: System administration > Security > Assign users to roles and System administration > Security > Security configuration.

Security hierarchy

Standard role-based access with four layers:

• Privileges: the smallest unit, grants access to a menu item / table / field at a specific permission level.
• Duties: a bundle of privileges representing a job task ("Maintain customer master").
• Roles: a bundle of duties representing a job ("Accounts Receivable Clerk").
• Users: assigned one or more roles.

Segregation of Duties (SoD)

Compliance feature: define rules that flag when one user holds duties that should be separated (e.g., "Create vendor" + "Process payment"). Violations surface for review / approval. Critical for SOX and external audit.

Extensible Data Security (XDS)

Row-level security: restrict data visibility based on context (e.g., a buyer sees only POs for their assigned commodity). Defined as policies with constraints; applied via role assignment.

Audit-friendly design

• Custom roles, never modify out-of-box duties / privileges (upgrade-safe).
• Naming convention prefix (e.g., CUS_) to identify customizations.
• Document each role's intent and approver.
• Quarterly access review: who has what role, validated by managers.

Azure AD integration

Users authenticate via Entra ID (Azure AD); license assignment per user. SSO with the rest of Microsoft 365 / Power Platform.

Where: Organization administration > Workflow > Workflows (cross-cutting), plus per-module workflow setup pages (e.g., Accounts payable > Setup > Accounts payable workflows).

Workflow types

Out-of-box workflow types per business object (purchase requisition, expense report, vendor invoice, journal, project budget, etc.). Each type has its own designer with object-specific actions.

Workflow elements

• Tasks: manual steps (review, approve).
• Approvals: multi-step approval chain.
• Automated tasks: system actions (e.g., post a journal).
• Conditional decisions: branches based on field values (e.g., amount > $X).
• Manual decisions: human routing choice.

Approval routing

• Position-based: route up the position hierarchy (manager, manager's manager).
• User-based: specific user.
• Group-based: any member of a workflow user group.
• Hierarchy-based: spending limits via signing-limit hierarchy.
• Queue-based: any user in the queue can pick up.

Parallel vs. serial

Parallel: multiple approvers work simultaneously, all must approve. Serial: one after another, in order. Mix both with branches.

Common pitfalls

• Long-running approvals because escalation timeouts not configured.
• Delegation broken (worker on PTO; no delegate set; approvals stack).
• Position hierarchy not published > routing fails.
• Workflow disabled by mistake during testing > documents skip approval.

Batch framework

Long-running and scheduled work happens in batch. Examples: master planning runs, financial period close, recurring data imports, electronic reporting, posting accumulated transactions.

Batch groups

Logical grouping mapped to batch processing servers / capacity. E.g., "DataIntegration" group, "Planning" group. Allows isolation: heavy planning jobs don't starve quick integration jobs.

Recurring batches

Scheduled job that re-creates itself on completion (or per cron expression). Pattern for daily loads, hourly polls, periodic close steps.

Monitoring

Where: System administration > Inquiries > Batch jobs. Status (Waiting, Executing, Ended, Error). Common-issue page: history of failures, error stack. Alerts can be configured to notify admins of failures.

Troubleshooting

• Batch stuck "Executing" with no progress > usually an orphaned job; cancel and re-run.
• Batch fails consistently > check error log in batch history; common causes are SQL deadlocks or missing input data.
• Performance: long-running jobs > profile via SQL trace and optimize the underlying X++ logic or indexing.

Where: System administration > Workspaces > Data management.

Data entities

Pre-built denormalized views over the underlying tables, designed for import / export. Hundreds shipped; extensible. Each entity has a target structure (Excel / CSV / XML / JSON) and a hidden mapping to base tables.

Import / export projects

Project = a collection of entities to load/extract together with a defined sequence (order matters: customer groups before customers, customers before customer transactions). Source format and field mapping per entity. Run as one logical unit.

Recurring data jobs

API-based recurring import (REST endpoint) or scheduled file pickup (Azure Blob, SFTP). Used for nightly integrations from external systems.

Performance & tuning

• Set-based vs. record-based: entities default to set-based (bulk SQL); some require record-based (slower); the decision matters for million-row loads.
• Multi-threading: partition source data; run parallel imports.
• Skip staging: for trusted source, skip the staging-table validation step (faster but risky).

Go-live data migration

The standard pattern for cutover: open balances, master data, open transactions all loaded via DMF projects. Multiple dry-run loads in test environments before final cutover. Master data refreshed continuously up to cutover; transactions loaded in the cutover window.

What it is

Where: System administration > Workspaces > Feature management. The toggle workspace for new and changing F&O capabilities. Microsoft ships features behind flags, allowing customers to opt in (or be auto-enabled at a future release) on their own timeline.

Feature states

• Preview: early access; not for production use unless explicitly stated.
• Available: generally available; opt-in.
• On by default (mandatory): auto-enabled at a stated release; cannot be turned off.
• Deprecated: being removed; turn-off date communicated in advance.

Why it matters operationally

Service updates (8+/year) bring new features. Without active management:

• Mandatory features turn on without notice and break unrelated process.
• New optional features that should be enabled (Planning Optimization, modern Expense, Subledger automation) sit unused.
• Deprecated features get turned off mid-cycle, surprising users.

Plan a quarterly Feature management review, comparing your enabled features to release notes; document approved features in a change log.

Per-environment vs. global

Most features toggle per environment (sandbox first, production after testing). A few are tenant-wide. Always test in sandbox before enabling in production, even when the feature is marked GA.

Feature dependencies

Some features require prerequisites (a parent feature, a configuration setting, a data migration step). Feature management surfaces dependencies; honor them or activation fails.

Lifecycle Services (LCS)

Microsoft's environment management portal. Provisions / refreshes / patches environments (TIER1 / TIER2 / SANDBOX / PROD). Holds Business Process Modeler (BPM) libraries, methodology templates, asset library (deployable packages, models), telemetry feeds.

Environments

• Tier 1 (developer): single-box, used for development. Customer-managed.
• Tier 2-5 (sandbox): Microsoft-managed, multi-box. UAT and integration testing.
• Production: Microsoft-managed, high-SLA. Refresh from prod > sandbox supported.

One Version & service updates

Microsoft pushes service updates (~8 per year, monthly cadence) automatically to all customers. Customers can pause one update; cannot skip indefinitely. Implies a continuous regression-testing discipline (RSAT, automated tests on key business processes).

Telemetry & monitoring

Performance metrics, errors, usage exposed via LCS Environment Monitoring > Application Insights. Production performance issues are diagnosed through these tools. F&O has its own SQL-execution-plan analyzer for query tuning.

Performance counters

Active users, batch throughput, page load time, SQL DTU consumption. Performance baseline established post-go-live; deviations tracked.

Sales tax authorities

Where: Tax > Indirect taxes > Sales tax > Sales tax authorities. The agency owed (state Dept. of Revenue, IRS, HMRC, etc.). Holds vendor account for payment, rounding, report layout.

Settlement periods

Frequency of filing per authority (monthly, quarterly, annual). Drives the periodic settle-and-post run.

Sales tax codes

The actual rate definitions: rate %, calculation method (per unit / per amount / interval-based), period link, ledger posting group. One code per rate variant per jurisdiction.

Ledger posting groups

Map sales tax codes to GL accounts: tax payable, tax receivable, use tax expense, tax adjustment. Multiple posting groups for different scenarios (interstate vs. intrastate, B2B vs. B2C).

Rounding

Per code: round to currency precision, half-up vs. banker's rounding, total-level vs. line-level rounding. Tax-authority rules vary; misalignment causes 1-cent variances in returns.

Where: Tax > Indirect taxes > Sales tax > Sales tax groups and Tax > Indirect taxes > Sales tax > Item sales tax groups.

Sales tax groups

Assigned to customer (sales side) or vendor (purchase side). Defines which tax codes could apply to that party. Often by jurisdiction: US-CA, US-NY, EU-DE, etc.

Item sales tax groups

Assigned to the item / service. Defines which tax codes could apply to that thing being sold. E.g., Food (taxable in some states, exempt in others), Service, Resale-eligible-item.

The intersection

The tax code applied = intersection of customer's group ∩ item's group. Both must contain the code for it to fire. Powerful: the same item is taxed differently by different customer types (direct vs. wholesaler), and the same customer pays different rates on different items, all without case logic.

Tax exemptions

Customer flagged exempt (resale certificate on file) or item flagged exempt (food) overrides the calculation. Document tax exemption certificate per customer with expiration tracking.

Ship-to vs. ship-from

For US sales tax (destination-based), the ship-to address determines jurisdiction. Customer address book stores tax group per address; sales order pulls from the delivery address.

Where: Tax > Indirect taxes > Withholding tax > Withholding tax codes; Intrastat under Tax > Declarations > Foreign trade > Intrastat.

Withholding tax

Buyer-deducted tax on certain payments (services, royalties). Setup: codes per withholding type, vendor flagged as subject to WHT. F&O reduces vendor payment by WHT amount and accrues the WHT liability.

Use tax (US)

Buyer self-assesses tax on out-of-state purchases when seller didn't collect. Configured as expected sales tax on the purchase side; the offset accrues use tax payable to the relevant state.

Reverse charge VAT (EU / UK / etc.)

For B2B cross-border: buyer self-accounts both the VAT charge AND VAT recovery (net zero ledger impact, but reported on VAT return). Configured per code with reverse-charge flag; F&O posts both legs automatically.

Intrastat (EU)

Statistical report of intra-EU goods movement (acquisitions and dispatches). F&O captures Intrastat-relevant fields on PO / SO (commodity code, weight, mode of transport, country of origin), generates the Intrastat report per period, files via Electronic Reporting.

Country-specific overlays

India GST: complex SGST / CGST / IGST split, e-invoice, e-way bill. Brazil: SPED, NF-e. Mexico: CFDI. Each handled via the Globalization Studio / ER configurations Microsoft delivers.

Settle and post sales tax

Where: Tax > Declarations > Sales tax > Settle and post sales tax. Run per settlement period. Aggregates all tax transactions in the period, posts a settlement journal moving balances from per-transaction tax accounts to the authority payable.

Sales tax payment

From settlement payable, generate AP payment to the tax authority's vendor record. Payment posts against the authority payable balance.

Tax reports & ER

Standard reports: Sales tax list, Sales tax specification by ledger transaction. Country-specific filings via Electronic Reporting (ER): GL boxes mapped to tax-return boxes, output as the format required (XML, JSON, CSV, PDF). Most countries with formal e-filing have a delivered ER configuration.

Reconciliation

Tax payable per GL must agree to the authority report and the eventual filed return. Periodic process: pull tax-listing report, compare to GL balance, investigate and adjust before submission.

Tax Calculation service

Microsoft's modern tax determination service (Globalization Studio). Handles complex multi-jurisdiction rules (US sales tax with thousands of jurisdictions). Available out of box for customers on the right SKU.

Vertex / Avalara integration

For US multi-state and many international scenarios, integrate via certified connector. F&O sends the transaction context (ship-from, ship-to, items, amounts); engine returns rate / tax. Engine maintains rate currency; F&O posts the result.

When to use external engines

• US sales tax with 5+ states.
• Use-tax determination at scale.
• VAT registration in many EU countries.
• Need exemption-certificate management (Avalara CertCapture).

When native is enough

• Single-country VAT with stable rates.
• One or two US states.
• Basic GST regime.

TMS parameters

Where: Transportation management > Setup > Transportation management parameters. Number sequences (loads, shipments, freight bills), default modes, default carrier-selection method.

Hub master

Physical locations in the network (own DCs, customer ship-tos, vendor pickup points, cross-docks). Hubs are typed (warehouse, customer, vendor) and used in route planning.

Transportation modes

Truck, rail, ocean, air. Per mode: equipment types (53' trailer, 20' container), service-level options.

Container types

Physical containers (TEU / FEU / LTL pallet) with dimensions / weight capacity. Drives load-build constraints.

Warehouse activation toggle

Per warehouse, "Use transportation management" enables TMS-driven rate calc / load planning for that warehouse. Without it, the warehouse uses simpler shipping setups.

Where: Transportation management > Setup > Carriers > Shipping carriers and Transportation management > Setup > Rating > Rate masters.

Shipping carriers & services

Carrier (UPS, FedEx, BNSF, Maersk) holds vendor link, contact info, modes supported. Carrier service (UPS Ground, FedEx Express) defines transit / commitments per carrier.

Rate masters & rate bases

Rate master = the contract / tariff. Rate base = the rate-lookup structure (origin / destination zones, weight breaks, surcharges). Calculate per shipment by traversing the rate-base tree.

Rate engines

Pluggable engines: standard table-driven, percent-based, weight-based, third-party integration. Per carrier, designate the engine that calculates its rates. Most operations use a mix (table for LTL, third-party API for parcel).

Zone master

Origin / destination zones (groups of zip / postal codes). Rate base lookups use zones to scale the master rate table.

Accessorial charges

Surcharges (fuel, residential, lift gate, hazmat). Per carrier and per condition; compounded into the final rate.

Where: Transportation management > Planning > Load planning workbench and Transportation management > Planning > Route plans.

Rate shopping

For a sales-order shipment, F&O queries all eligible carriers and returns rates / transit times. Selection rule (cheapest, fastest, preferred) chooses one. Result attached to the sales-order shipment.

Route planning

Multi-stop routes for a single truck visiting multiple ship-tos. Route plan auto-builds based on geography, time windows, capacity. Manual overrides allowed.

Load building workbench

Visual tool to combine sales orders / transfer orders into a load (truck-equivalent). Drag-drop with weight / cube / pallet capacity feedback. Saves built loads for execution.

Appointment scheduling

For inbound: vendor / carrier requests dock appointment; scheduler approves based on dock capacity. For outbound: arrange customer-receiving appointment.

Link to WMS waves

Loads drive wave creation in Warehouse Management. Pick-pack flows align to load departure schedule, ensuring the right work is prioritized.

Where: Transportation management > Periodic tasks > Match freight bills and reconcile and Transportation management > Inquiries and reports > Freight bill details.

Freight bill

The carrier's invoice for a shipment. Generated from confirmed shipment data (using rate engine result) or imported from carrier (EDI 210, file).

Audit

Compare carrier-invoiced amount to F&O-calculated amount. Variances flagged for review: incorrect rate, missed accessorial, weight discrepancy. Approved amount becomes the AP-bound charge.

Freight reconciliation

Match shipments <> freight bills <> AP invoices. Open shipments without a freight bill flagged; freight bills without shipment matched flagged. Run periodically to keep AP / freight ledger clean.

Posting to AP

Approved freight bills generate AP vendor invoices to the carrier. Cost charges to inventory (inbound) via misc charges or to expense (outbound) per posting profile.

Full TMS justified when

• Annual freight spend is significant (rough threshold: $5M+ where 1-2% optimization pays for the project).
• Multi-stop routing or load building drives meaningful efficiency.
• Multiple carriers / modes with negotiated contracts (rate audit catches errors).
• Internal freight team to maintain rate masters, audit invoices.

Skip / simpler alternatives

• Standard parcel: Use the standard UPS / FedEx / DHL connectors for label / rate without TMS.
• Misc charges on PO / SO: for simple known-rate freight.
• External TMS (project44, Manhattan, BluJay/E2open): for complex enterprise TMS; integrate with F&O via API / EDI.

Data prerequisites

• Item dimensions (weight, cube) accurate, or load building fails.
• Address geocoding / zone alignment correct.
• Customer ship-to addresses with delivery windows.
• Carrier rate sheets in usable format for rate-base load.

Activate at the vendor level

Where: on the vendor record, Vendor collaboration > Configuration. Set the Vendor collaboration activation field per vendor: not active (no portal access), active for invoice processing, active for procurement, active for the full set.

Procurement parameters

Under Procurement and sourcing > Setup > Procurement and sourcing parameters > Vendor collaboration, configure approval workflow for new vendor requests, defaults for prospective vendor records, and the legal entity scope.

Azure AD B2B

External vendor users authenticate via Azure AD B2B (their own organization's identity, invited as a guest in your tenant). Setup follows the standard B2B invitation flow; the user is then assigned vendor security roles in F&O.

Vendor security roles

• Vendor admin: manages other vendor users, vendor profile, banks.
• Vendor (procurement): sees POs, confirms / rejects, responds to RFQs.
• Vendor (accounts payable): submits invoices, views payment status.
• Custom vendor roles can extend or restrict per company policy.

Where: Procurement and sourcing > Vendors > Prospective vendors and the public registration URL configured in Procurement and sourcing > Setup > Procurement and sourcing parameters > Vendor collaboration.

The full onboarding flow:

1. Prospective vendor visits the registration URL and submits company details, certifications, banking info.
2. F&O creates a Prospective vendor request and routes it through approval workflow (procurement > legal > finance).
3. On approval, a Vendor Account is auto-created with the configured group, posting profile, hold status.
4. The vendor receives portal access via Azure AD B2B; they can then update their own profile, bank accounts (with approval), and certifications going forward.

The flow eliminates manual vendor-creation work for the procurement team and produces a clean audit trail of who approved each new vendor.

Purchase order confirmation

Vendor sees pending POs on their portal home page. They can confirm, partially confirm, or reject with reason. Confirmation triggers a PO confirmation event in F&O; rejection routes back to the buyer.

RFQ response

Vendor receives RFQ invitation, enters bid pricing and lead times directly in the portal. Bids close at the deadline; F&O's bidding workspace then handles award.

Invoice submission

Vendor uploads invoices directly (PDF + line data), referencing PO numbers. F&O matches against the PO automatically; on success the invoice posts as a Pending vendor invoice for AP review.

Consignment inventory visibility

For consignment models, vendors can view stock-on-hand at the customer site, replenishment alerts, and consumption reports, eliminating phone calls and email exchanges.

Vendors maintain their own contact info, addresses, tax registrations, certifications, insurance documents, and bank accounts (with approval workflow for bank changes). Catalog updates (new SKUs, price changes) are submitted through the portal and routed through procurement approval before going live in F&O.

This shifts data-entry burden from the buying organization to the vendor, where data quality is best (the vendor knows their own info).

• Soft launch with a pilot. Roll out to 10-20 friendly vendors first; iron out the registration / portal UX before mass invitation.
• Communicate clearly. Vendors will resist new platforms unless they see value (faster payment, real-time PO visibility). Make the value explicit.
• Adoption ramps slowly. Expect 30-50% adoption in year one; the laggards often respond only when payment-related communication is portal-only.
• Don't over-customize. The portal UI is configurable to a point; deep customizations break with future updates and burn maintenance budget.
• Beware bank-account-change fraud. Vendor portal makes bank changes easy, ensure the approval workflow on bank-account changes is rigorous (multi-person approval, callback verification).

Warehouse activation

Where: on the warehouse, the "Use warehouse management processes" toggle. Once enabled, all transactions in that warehouse follow the WMS path; the legacy basic warehousing flow is no longer available. Activation is one-way once stock exists.

Location formats and profiles

Where: Warehouse management > Setup > Warehouse > Location formats. Location format defines the structure of location IDs (Aisle-Rack-Shelf-Bin). Location profiles define the physical attributes (allow license plates, allow batches, picking zone, capacity).

Reservation hierarchy

WMS-enabled items typically use a reservation hierarchy that reserves only Site / Warehouse / Inventory status at order entry, deferring location / batch / serial reservation until picking work runs. Critical for warehouse efficiency.

Warehouse parameters

Default work creation, allowed work types, mobile device session timeouts, label printing defaults all live in WHM parameters. Match to operational reality.

Locations

Created per location format, assigned a profile, optionally tied to a Zone (logical grouping for picking strategy). Capacity (volumetric / weight) and constraints (single-item, single-batch) drive put-away logic.

Zones

Logical groupings used by location directives and work templates: receiving zone, bulk storage, pick zone, shipping zone. Drives wave behavior and replenishment routing.

License plates

Container ID (pallet, tote, carton) carrying inventory. Used to move multi-line containers as a single unit, label-printed, scannable on mobile. License plate enabled per location profile.

Wave templates and load planning

Wave templates group sales / transfer orders for batched picking work. Loads aggregate orders for shipment via a single carrier / route. Pre-configure wave templates per warehouse activity pattern.

Work templates

Where: Warehouse management > Setup > Work > Work templates. Define work creation rules per work order type (sales pick, purchase put-away, transfer, replenishment, return). Each template contains work types (Pick, Put) and the conditions under which they apply.

Location directives

Per work type per warehouse, define which location to pick from / put to. FIFO / LIFO / fixed location strategies all configured here. The combinatorial complexity is real, keep directives manageable per warehouse.

Wave processing

Sales orders are released to the warehouse and waved (grouped). Wave template runs work creation, optionally allocation, optionally containerization. Waves can be auto-created on order release or manual.

Work users and pools

Workers are assigned to warehouse work pools determining what work types they can pick up. A worker logs into the mobile app, sees their queue, executes work step-by-step.

App architecture

The current Warehouse Management mobile app (Microsoft-shipped, replacing the older Warehouse Mobile App) connects to F&O via a service endpoint. Workers log in with a Worker ID; menu items drive specific tasks: Receive, Put-away, Pick, Cycle count, Inquiry.

Mobile device menu items

Where: Warehouse management > Setup > Mobile device > Mobile device menu items. Each menu item maps to a work type and behavior (auto-confirm, prompt for license plate, etc.). Custom menu items extend default behavior; deep customization is possible but each customization is technical debt for upgrades.

Common flows

• Receive: scan PO + items + license plate; the receipt auto-creates put-away work.
• Put-away: scan license plate, follow directives to drop location.
• Pick: follow waved work, scan items, confirm, drop at staging.
• Ship-confirm: close out the load, generate ASN to customer if applicable.
• Cycle count: scan location, confirm count, post variance.

Offline mode

The mobile app does not have full offline capability; some basic work can be queued when network is unavailable, but most operations require connectivity. Plan warehouse Wi-Fi accordingly.

Cycle count plans

Where: Warehouse management > Setup > Inventory > Cycle counting. Threshold-based (count when stock drops below X), zero-count (count empty locations to confirm), spot-count (manual ad-hoc), schedule-based (count by zone every N days).

Replenishment

Three patterns:

• Wave demand replenishment: when a wave needs stock and pick locations are low, replenishment work is auto-created from bulk to pick.
• Min/max replenishment: location-based stock targets trigger replenishment from bulk.
• Load demand replenishment: for cross-dock scenarios, replenish from inbound directly to outbound.

WHS cleanup jobs

Where: Warehouse management > Periodic tasks > Cleanup. Critical batch jobs to remove old work, container statuses, mobile device session data. Without scheduled cleanup, WHS tables grow and the warehouse slows down.

• WMS is a project of its own. Don't treat it as a sub-stream of an SCM go-live; the design / test / pilot / training cycle for WMS often equals the rest of the implementation.
• Volume justifies WMS. Below ~50 picks per day per warehouse, basic warehousing is often more efficient.
• Wave templates are tunable. Default templates rarely fit; expect 6-12 weeks of iteration on wave parameters during UAT.
• License plates require label printing. Label printers, label formats, and integration are warehouse infrastructure; budget for it.
• WHS cleanup not optional. If you don't schedule cleanup, the warehouse will eventually slow to a crawl.