The most important lesson in the module, and possibly in the phase.
An LDG is a hard partition, not a filter. Payroll definitions, elements, rates, balances and the related setup live inside one and are not visible outside it. That word is the whole lesson: a filter hides things that are still there; a partition means they genuinely are not, and there is no permission you can grant that reaches across it.
The default rule: one LDG per country you employ people in. Start there, and deviate only with a reason.
When do you need more than one in a country? Genuinely rare. Reasons that sometimes qualify: legally separate payroll operations that must not share element definitions, or an acquired entity kept fully separate during a transition. Reasons that do not: "different divisions", "different pay frequencies", "it feels tidier". Pay frequency is the one that catches people — it is handled by payroll definitions within an LDG and is not a reason to partition. And fewer? Almost never: sharing an LDG across countries with different legislations is not viable, because the legislation is what the partition is aligned to.
The costs run in both directions. Extra LDGs: every element, rate and payroll definition is created once per LDG, so two in one country doubles your payroll configuration and doubles the maintenance forever — every future change made twice, until the two copies diverge, which is worse than either. Too few: you cannot separate what the law requires you to separate, and there is no retrofit. Notice the asymmetry: too many is expensive, too few is unfixable.
Write the rule down: count the legislations you employ people in; that is your starting LDG count; deviate only with a written, client-signed reason. Signed, not agreed in a meeting — because this is the decision you will be asked about in three years, and by then everyone will remember it differently.
And the sentence that creates re-implementations: "payroll is out of scope" is not a reason to skip this. LDGs are required for the structure regardless, and they constrain what a future payroll implementation can do. The team arriving in year three inherits whatever you decided in week three of year one, and if you got it wrong because payroll was not in scope, their options are re-implementation or living with it. So when you hear "we are not doing payroll yet", the answer is: understood, and we still design the LDGs properly — because the alternative is deciding your successor's constraints by accident.