Follow a purchase and a sale from operational document to balanced ledger entry, and learn exactly which piece of configuration chose each account. The posting profile map, physical versus financial updates, and how to diagnose a posting you did not expect.
There is one question that dominates the first year of anybody's D365 Finance & Operations career: why did this transaction post there?
A voucher is the accounting document: a unique number carrying a balanced set of ledger entries for one accounting event. Debits equal credits. Each line carries a main account, a set of financial dimension values, an amount in the transaction currency and in the accounting currency, a posting layer and a date.
This is the concept that most often catches people arriving from a smaller ERP, where only the invoice touches the ledger.
No ledger posting. The order is a commitment, not a transaction. (Where a business needs encumbrance accounting, budget control provides it separately.)
Note what is not here: revenue. Revenue is not recognised on delivery in this model; the invoice does that.
Two rows in that table catch people repeatedly. Revenue comes from the inventory posting profile, not from the customer, which surprises anyone expecting revenue to follow the customer group.
These two objects have almost the same name and completely different jobs. Learn the split once and it stays learned.
Sooner or later a figure appears in an account that nobody expected. The system provides a path back, and knowing it turns a two-day investigation into a ten-minute one.
Because subledgers and the ledger are produced by the same posting event, they agree — provided the configuration is coherent. Making that provable is part of the design, not an operational afterthought.
The posting engine is where operational reality becomes accounting reality, and D365 spreads that translation across the modules that own each process.