How Maconomy's distributed posting configuration — spanning customer invoicing, receipts, vendor invoices, payments, expense, timesheets, project cost, procurement and job billing — translates into D365's posting profiles, project categories and ledger posting groups, with a fully worked timesheet-to-voucher example.
The posting engine is the mechanism by which operational events — a timesheet approval, a customer invoice, a vendor payment, a project-expense claim — produce accounting entries in the general ledger.
Maconomy derives accounting entries from configuration that spans multiple areas. For each transaction type, the configuration determines:
In Maconomy, a customer invoice creates a debit to the receivable/control account and credits to revenue, tax and (for project invoices) project-revenue accounts. The configuration determines which accounts are hit based on the invoice type, customer group, project and tax treatment.
Vendor invoices in Maconomy debit expense, procurement accrual, project cost, asset or tax accounts and credit the vendor payable. D365 splits this:
Maconomy expense posting distinguishes reimbursable, corporate-card, non-reimbursable, billable and non-billable lines. D365 Expense Management uses:
This is the core professional-services posting path. When a timesheet is approved, the hours post to the project as a cost transaction. The accounting depends on the project type:
When a purchase order is receipted (whether for stock, project consumption or direct expense):
Maconomy's job invoice proposal is a staging object — it selects eligible transactions, groups them by contract or customer, allows write-up/down and narrative adjustment, and presents the draft for approval. No accounting impact occurs until the invoice posts.
This is the area of greatest uncertainty in a Maconomy migration. Public evidence confirms that Maconomy supports progress evaluation and project-accounting concepts, but the specific formulas — completion basis, measure, loss provision, true-up, contract modification and close treatment — are client-specific and cannot be assumed from…
For migration testing, build a transaction catalogue that states the expected debit, credit, main-account source and dimension source for each family:
Maconomy's posting engine is distributed, not centralised. There is no single table to export and no mechanical conversion path. The migration is a per-family design exercise: discover the source rules, understand the intent, and re-express that intent through the appropriate D365 posting-profile surface.