What Is Sub-Customer Billing?

Sub-customer billing is the practice of issuing invoices to one account while routing the collection to a different, related account, because the entity that buys and the entity that pays are rarely the same. Monk is an AI-native invoice-to-cash platform that runs invoicing, AP portal submission, collections and cash application as one system, and in Monk, sub-customer billing means the invoice keeps the detail of the child account while the outreach, the playbook and the aging roll up to the parent that releases the payment.

The concept has different names depending on your ERP. QuickBooks calls them sub-customers. NetSuite calls them parent companies. Sage, SAP and Dynamics each have a variant. The principle underneath is always the same: a hierarchy of accounts where some entities consume a service or place an order, and another entity pays for it.

Where does this come up?

Everywhere a business has more than one billing entity behind a single payer.

A staffing company places contractors at three divisions of a national client. Each division has its own cost center, its own approver and its own PO series. One AP department in Omaha cuts a single check for all three on the 15th of every month. The staffing company sends three invoices. It should send one consolidated collection.

A SaaS company sells seats to a holding company that deploys them across four subsidiaries. Each subsidiary has its own contract, its own renewal date and its own billing contact. But the holding company's finance team consolidates all the invoices onto one payment run and wants a single statement.

A food distributor invoices 14 restaurant locations. The corporate office pays. The site managers have no idea their location even receives invoices, and they have no authority to release payment.

In all three cases the invoicing is correct. Each child entity gets the right line items at the right price against the right PO. The problem starts the moment a collection goes out, because the system does not know that these 14 records resolve to one payer.

What happens when collections run against child accounts?

Here is a specific version of how it goes wrong, assembled from the kind of scenario that comes up in qualifying calls with mid-market finance teams.

A distributor has 14 restaurant locations as separate customer records. Corporate AP in Denver pays all 14 on the same monthly schedule. The collection system does not know about the parent, so it sends 14 separate reminder threads, each containing one invoice, each addressed to the contact on the child record. That contact is usually the general manager of the restaurant, who has no visibility into the payment process and no authority to release anything.

The GM at location six forwards the reminder to a corporate office, but the GM at location nine ignores it. The GM at location two replies asking what this is about, creating a conversation thread that a collector now has to manage. Corporate AP, meanwhile, has already scheduled the payment for the 15th.

By the time the collector realizes all 14 records belong to one payer, they have sent 14 emails, received five confused replies, and created three open conversation threads about money that was never at risk. The corporate AP team has received four forwarded emails from four different locations, all with slightly different wording because the playbook ran at different cadences depending on when each child invoice was issued.

Most AR systems store a flat customer list, and this is their default behavior.

What does this do to your aging report?

The aging report becomes unreliable in a way that is hard to spot because the numbers look plausible individually.

Each of the 14 child accounts shows a balance. Say the invoices average $4,500 each. In the 1-to-30 bucket, 14 entries at $4,500 each do not look alarming. None of them clears the threshold where a collector would escalate.

Roll them up to the parent and the picture changes. One customer owes $63,000 across 14 invoices, all on the same payment cycle. If that payment cycle slips by 10 days, the exposure is $63,000, not $4,500. The concentration risk is invisible in the child-level view, and concentration is the thing that matters for credit decisions and cash forecasting. A collector working the aging report by child records will always deprioritize these.

How should it be structured?

The child account holds the invoice detail: line items, service periods, PO references, delivery evidence. This is where three-way matching happens and where disputes get resolved, because a dispute about catering supplies at the Austin location concerns the Austin location's PO, not the corporate parent.

The parent account holds the collection. Outreach goes to the parent's AP contacts. The playbook runs at the parent level. Promised dates sit on the parent. Credit risk is assessed at the parent level. When a collector opens the parent, they see every open invoice from every child, the combined balance, and the aging.

Children inherit the parent's playbook and assignment rules. If corporate AP is assigned to Sarah and runs on Playbook B, every child rolls up to Sarah and Playbook B without a separate configuration step. Adding a 15th restaurant location should not require anyone to remember to set up collection rules. If it does, the 15th location will quietly age for a month before someone notices.

There is one setting that eliminates most of the contact confusion: when a child account is billed to its parent, the child's contacts do not appear in collection outreach. The email goes to the parent's AP contacts, because those are the people who can act on it.

What about the ERP? Does it handle this?

Partly. The gap between what an ERP stores and what it does with that data is where sub-customer billing falls apart.

QuickBooks lets you nest sub-customers and roll up reporting. NetSuite has a parent company field and subsidiary records. Sage, Dynamics and SAP each represent the hierarchy in their own way. All of them store the relationship. All of them can print a consolidated statement.

None of them route the collection through the parent by default. An ERP dunning run sends the reminder to whoever sits on the child customer's contact record, because that is the record it is working from. Credit holds apply at the entity level. Aging reports filter by entity, and the parent total only exists if somebody builds a custom saved search.

An AR system that imports the hierarchy from the ERP and then ignores it for collections has reproduced the flat list with an extra column. The hierarchy is only useful if it changes where outreach goes, which contacts get emailed, and how the aging is calculated.

How do you handle exceptions inside a hierarchy?

Not every child should inherit every rule. The important thing is that inheritance is the default and an override is visible.

A child with its own payment terms, negotiated during a one-off deal two years ago, should be billed and collected on those terms. But if nobody remembers the negotiation, the child ages quietly under the parent's Net 30 while the contract says Net 60. Mark the override when it is created and review it at every credit cycle.

A child in a different country may have a different currency, a different tax regime and a different AP team. Treating it as part of the domestic parent's collection run sends the wrong reminders to the wrong people in the wrong currency.

A child placed on hold for a dispute should stop sending, while the rest of the hierarchy continues. Pausing the parent over one disputed child invoice stops collection on the entire $63,000 balance, which is the wrong response.

Each of these is a per-child override, and the system should surface that the override exists. A collector opening the parent should see that 13 of 14 children follow the standard rules and one does not.

How does Monk handle this?

When a child account is billed to its parent in Monk, everything routes to the parent. The collection email goes to the parent's contacts, the invoice sits under the parent's collection account, and children inherit the parent's playbook and assignment rules. Children no longer appear in contact review, because their contacts are not the ones who release payment.

The collector sees one consolidated view. Every invoice from every child, the combined balance, the aging distribution, all in one place. Julia, Monk's AI agent for Intelligent Collections, drafts outreach against the full parent context, so a single message to corporate AP can reference the right invoices across the right children. Julia achieves a 24% higher response rate than standard dunning.

The underlying invoices still carry child-level detail. When AP asks about the service period on the Austin location's invoice, the answer is there. When a dispute concerns one child's PO, the dispute is scoped to that child while collections continue on the rest.

Monk works with QuickBooks, NetSuite, Salesforce, HubSpot and Stripe, and is SOC 2 Type II compliant. Teams using Monk report a 40% average reduction in DSO, and go-live takes one to three days.

Where should you start?

Pull up your 10 largest accounts by outstanding balance. For each one, answer two questions: does this customer have related entities billing separately, and are those entities collecting through the same AP department?

Most teams find that at least half of these relationships exist only in a collector's head. The parent is not represented in the system, or the parent record exists but collections still run against the children.

Then open your aging report and look for clusters: five or six child records with similar names, similar balances and similar aging. Those clusters are parents in disguise, and the combined exposure is what you should be looking at when you set credit limits or forecast cash. To see parent-child billing, consolidated collections and playbook inheritance working on your own accounts, book a demo.

Frequently Asked Questions

What happens when two parents share a child entity?

Some businesses have a location that bills to one corporate entity for certain services and a different corporate entity for others. The child should be linked to the parent whose AP team pays the relevant invoices. If a single child splits across two payers, it usually needs to be two records, each linked to its own parent, because collections cannot route one invoice to two payment authorities.

How do you handle a parent that pays some children but not others?

Link only the children the parent pays for. A subsidiary with its own AP department, its own payment run and its own credit profile is a separate customer, not a child. The test is whether one AP team controls the payment for that entity. If it does not, the hierarchy misleads rather than helps.

What happens to a child's collection thread when it moves from one parent to another?

This comes up during acquisitions and reorganizations. The collection history should follow the invoice, not the parent, so open threads and promised dates stay visible after the reassignment. The playbook switches to the new parent's rules going forward, and any in-flight drafts should be reviewed before they send under the new parent's cadence.

Can you set different escalation rules for different children under the same parent?

Yes, and you should when the children carry different risk profiles. A child in a regulated industry with a strict procurement process may need a softer escalation path than a child in the same hierarchy that routinely short-pays. The default inherits from the parent, but per-child overrides should be available and visible.

How does sub-customer billing affect cash application?

When a parent pays in a lump sum covering invoices from multiple children, cash application needs to allocate across the children. A single wire for $63,000 covering 14 child invoices requires either a remittance advice listing each invoice or an intelligent matching system that can break the amount across open items. Without the parent-child link, the cash sits unapplied because no single child's balance matches the wire amount.

Does Monk support sub-customer billing?

Yes. When a child account is billed to its parent in Monk, the collection email goes to the parent's contacts, children inherit the parent's playbook and assignment rules, and the collector sees a consolidated view with every invoice from every child.