Actual Duration Calculated by MS Project vs Actual Duration of the Project as of the Status Date

The “Actual Duration” of an in-progress summary task (including a project summary task) in MSP is NOT the same as – nor even closely related to – the elapsed work days from the start of the summary to the Status Date. Rather, the actual duration of the summary is the product of its duration and its %complete, where the latter is computed as a duration-weighted average of the %completes of its sub-tasks.

That is, for a summary task,

1. Duration = ProjDateDiff ([Start],[Finish]) (The difference between the rolled-up start and finish dates, using the applicable calendar)
2. %Complete = Σ[Subtask Actual Durations] / Σ[Subtask Durations]
3. Actual Duration = Duration * %Complete
4. Remaining Duration = Duration - Actual Duration

The summary task’s rate of progress (as timewise increase in %complete or Actual Duration) is highest when many of its subtasks are being executed concurrently and lowest when only one or two subtasks can be executed at a time. Consequently, for a typical complex project that is running exactly according to plan, the indicated progress of the project summary task (as Actual Duration) will start out trailing the Status Date during the initial ramp-up period but will lead the Status Date substantially by the end of the main execution period (prior to ramp-down). Thus, your indicated Actual Duration of ~90+ days at a Status Date that is 80 days into a 100-day project seems unremarkable. That said, it is not a valid substitute for critical path analysis, earned valued analysis, or other suitable forecasting methods.

I think the simple answer is that you have a mismatch between the calendar you are using to manually calculate duration and the standard calendar MSProject is using to calculate it. You need to build a calendar in MSProject to match what you are using offline. Or, just simply use MSProject's definition of the calendar and its duration outcome.