Project management, pegging, and revenue recognition

How Infor LN's project structure, project pegging through the supply chain, and progress invoicing translate to D365 Project management and accounting — and an honest assessment of where the fit is imperfect.

What you will be able to do

Introduction

Project management and accounting is the module where LN's defining concept — Project Pegging — confronts D365's project model most directly. The source material does not soften this: project pegging is described as the single hardest LN concept to reproduce faithfully in D365, and that assessment is accurate.

LN project types and structure

LN's project capability spans two conceptual paradigms, which must not be conflated.

Project pegging through the supply chain

Project pegging is the mechanism that binds supply-chain transactions to project activities in LN. The peg reference travels from the project activity through every supply chain tier that generates costs for the project.

Budgets, cost control, and progress invoicing

LN's project cost control model operates at the activity level. Each activity carries an original budget, approved extensions, committed costs (open purchase orders and production orders), actual costs, and a forecast-to-complete.

Revenue recognition in LN and D365

Percentage-complete (POC) recognises revenue in proportion to the physical or cost-based completion of the project. LN calculates a completion percentage at period end and posts an accrued-revenue entry to the project WIP account (debiting a WIP account and crediting a revenue account) until the project is complete and final invoicing…

The carryover options

At cutover, in-flight project-pegged transactions must be handled explicitly. Three options exist:

Project pegging in the canonical model

Project pegging cannot be treated as a comment on an order line. In the canonical model it is a first-class attribute because it changes both planning interpretation and accounting intent. The migration model uses six entities to make that explicit:

Knowledge check

Summary

LN's project capability is deep, and the migration must respect that depth honestly.