Importance of this feature

Without this workflow, users manually reassign payments or maintain separate tracking for each subsidiary. This leads to:

• Unpredictable reconciliation behavior

• Difficulty maintaining centralized AR balances

• Higher manual intervention across teams

With this feature enabled:

• Payments are automatically associated with the Parent account

• You can apply the payment to invoices of any Child or Grandchild entity

• Reconciliation, reporting, and aging become cleaner and centralized

Understanding Parent–Child behavior

Consider the following group structure for example:

Wayne Enterprises Global - Grandparent / Super Parent

1. Wayne Canada - Parent

   • Wayne Montreal - Child / Leaf node

2. Wayne US - Parent

   • Wayne Gothem - Child / Leaf node

   • Wayne Texas - Child / Leaf node

Default (without feature enabled): If a payment description reads "Payment made for Wayne Montreal", the system may match to Montreal directly. That payment then cannot be used to close invoices for Canada or Gothem.

With Parent–Child feature enabled: Any payment identified to any member of the group is automatically reassigned to the Parent (Wayne Enterprises Global). Then can it can be used to close:

1. Montreal invoices

2. All the US invoices (including Gothem and Texas)

The way the system works

• Payment is identified for any Child or Grandchild: Payment is automatically moved to the Parent

• Remittance is attached to the payment: Remittance moves along with the payment

• Invoices belong to any entity in the group: All are eligible to be closed with that payment

Important caveat

Case 1 - No hierarchy defined

If no Parent–Child relationship is defined in your system's customer master, our SmartAI will not infer or "guess" the relationship. The system depends entirely on the existing dataset hierarchy.

In short: No defined Parent–Child = No grouping behavior.

This ensures

• Predictability

• No accidental merging of unrelated accounts

• Clean and auditable posting behavior

Case 2 — Behavior when "Always Post to Immediate Parent" is enabled

When "Always post to Immediate Parent" is enabled (as shown in the Settings screenshot):

• Payments from child accounts will be rolled up only one level up to the direct/immediate parent.

• If a payment references multiple customers, the system will roll it up to the nearest common parent (the lowest shared parent in the hierarchy).

• The payment will not continue rolling up to the topmost or ultimate parent.

When this option is disabled: (Recommended)

• Payments continue rolling upward through the hierarchy

• Until they reach the Group Head / Grandparent / Super Parent

Behavior summary (plain language)

• Immediate Parent Enabled →

  Payment is stored at the immediate parent, even if there is a higher-level group parent. In the above example, the Payment with description "Payment made for Wayne Montreal" would get matched with Wayne Canada.

• Immediate Parent Disabled →

  Payment keeps rolling upward until it reaches the highest-level parent in the hierarchy. In the above example, the Payment with description "Payment made for Wayne Montreal" would get matched with Wayne Global.

Enable this feature

1. Go to Settings > Cash Application > Parent & Child Configuration

2. Toggle Enable Parent–Child Payment Mapping.

3. Ensure your Customer Master Data reflects accurate hierarchy.

   Note:

   This does not affect CRM workflows or customer visibility.

Key considerations

1. Remittance will move when the payment is reassigned. Remittance remains tied to the payment and moves along with it.
2. If the description contains multiple entities, Default → No match. With Parent–Child enabled → Mapped to the common Parent.
3. This works across ERPs.
4. If the org says they have a hierarchy but hasn't configured it, the system will not infer. ML requires a defined structure. An alternative of Split Payment can be used in this case.