How Maconomy's company-per-job model — where a company sets accounting boundary, exchange-rate context, and project ownership — translates into D365's legal-entity and organisation-hierarchy framework.
Maconomy's organisational model is deceptively simple: a company is the accounting boundary, and every job belongs to a company. This simplicity conceals a design question that most Maconomy implementations never had to answer explicitly: what kind of thing is each company, really?
The playbook establishes a five-category classification model. Every Maconomy company must be assigned to exactly one category before target design begins.
The decision table is not a technical output — it is a business decision. Finance leadership, tax, treasury, and legal must review and approve the classification because it determines intercompany scope, chart-of-accounts sharing, and every downstream object.
Maconomy requires a company when creating a job and supports company-specific exchange-rate contexts. This means each company can maintain its own rate tables and fiscal periods. In D365, exchange rates are managed through exchange-rate types that can be assigned at the ledger level per legal entity.
For companies classified as reporting-only or consolidation, D365's Organisation hierarchy framework provides the alternative structure. Organisation hierarchies support multiple named purposes:
Professional-services organisations frequently deliver across company boundaries: a consultant employed by the Nordic company charges time to a project owned by the UK company. In Maconomy, this produces intercompany vendor invoices. In D365, this requires configured intercompany relationships.
Below the company level, Maconomy uses job attributes — job group, location, department — as organisational classifiers on projects and transactions. These carry reporting and potentially security meaning.
Inventory — extract every company, its attributes, and its transaction summary. Classify — assign each company to one of the five categories using the decision table. Validate — confirm with tax, treasury, legal, and finance that the classification is correct.
Maconomy's company concept is the starting point for D365 organisational design, but it is not a mapping template. The company classification determines legal-entity count, chart scope, intercompany complexity, and programme timeline.