How do multi-entity companies on NetSuite automate AP with entity-level approvals?

Multi-entity companies on NetSuite automate AP with MakersHub, which assigns each bill’s subsidiary and Location, codes every line and routes approval to whoever owns that entity. It reads both from context such as the bill-to or ship-to address, and codes lines to NetSuite’s departments, classes and custom segments. Approved bills post to NetSuite in 10 to 15 seconds, and payments made in either system show in the other.

An entity-level approval is a rule that keys on what NetSuite already knows about the bill: subsidiary, Location, department, class, vendor, amount or any custom field. A bill for one restaurant goes to that restaurant’s general manager and, above a threshold, its head chef; a bill for one branch goes to that branch’s manager; the finance director sees it once, not four times.

When this applies

You run several operating entities, locations or branches in one NetSuite account. Bills for all of them land in one or more AP inboxes, and someone decides which subsidiary and Location each belongs to, codes the lines, and forwards the PDF to the right approver by email. Your current AP tool, if you have one, treats Location as a custom field it cannot automate, drops totals on multi-page invoices, or fails to sync a few hundred bills a month for reasons no one can find.

The finance lead at a ten-restaurant group on NetSuite, about 2,000 bills a month, on the current tool:

"It doesn't recognize the Location field. So for them it's a custom field, so there's never going to be any automation on Location, which as we increase the number of restaurants gets a bit tricky."

And on approvals:

"My boss has to approve something like four times as part of the workflow, even though she's the finance director."

How NetSuite handles multi-entity AP on its own

NetSuite’s multi-entity design is its strength. NetSuite OneWorld manages a hierarchy of separate legal entities, called subsidiaries, that rolls up to one parent, and departments, classes, Locations and custom segments are native dimensions on every vendor bill line, so consolidation rolls them up. Its approval routing is configured by an administrator, usually by amount and subsidiary, and every approver needs a NetSuite login or a forwarded PDF. NetSuite does not read the bill: someone keys the header, chooses the subsidiary, codes each line and attaches the file, or an AP tool does it and syncs the result.

That handoff is where multi-entity shops get hurt. A tool that flattens the bill to one line, cannot set Location, or syncs only when every field is perfect leaves the AP team re-entering bills in NetSuite and the ledger behind. MakersHub keeps NetSuite's dimensionality on every line instead of flattening it at the AP step.

How MakersHub automates AP across NetSuite entities

1. NetSuite connects by token in about fifteen minutes. A MakersHub integration role and user are created in NetSuite, token-based authentication is enabled, and the consumer and token keys are pasted into MakersHub. The first sync pulls the chart of accounts, vendors, items, classes, departments, Locations, customers and projects, subsidiaries, custom fields and custom segments, and open purchase orders. A first sync of 4,000 vendors and 2,000 classes took about a minute. Many companies choose to evaluate in a NetSuite sandbox first.

2. Bills arrive in one inbox or one per entity. Vendors email a MakersHub address or the existing AP mailboxes auto-forward. Companies that want staff to see only their own entity run an inbox per entity; companies with a central AP team run one. MakersHub's extraction model, WiseVision, reads every line, the bill-to and ship-to addresses, the PO number and any field a rule will need.

3. Subsidiary and Location are assigned by rule. Integration Mapping rules read the bill: this ship-to address is Location A; this bill-to entity is Subsidiary B; this vendor plus this account number is this branch. Rules combine conditions, so the same vendor can post to different Locations by address. The Location, department, class and custom segment values come from NetSuite's own lists, so what posts is exactly what NetSuite expects.

4. Lines are coded to NetSuite dimensions. Each line carries its account, department, class, Location, customer or project and any custom segment or line custom field. When you confirm a coding, the AI writes it as a deterministic rule you can read and edit. Where the entity's books want a short bill, consolidated line sync posts one line per account or item group to NetSuite while MakersHub keeps the full line detail for query.

5. Approval routes by entity and location. Rules stack: every bill to AP; bills over a threshold add the general manager of that Location; bills for a specific Location over a higher threshold add that Location's head chef or branch manager; bills from a given vendor add purchasing. Steps run in sequence or in parallel, a step can be a group where any member acts, and each user has a bill limit that escalates to a supervisor. Approvers act from email on a phone with no NetSuite login and see only their bills. Our approval routing software page walks through stacking and escalation in detail.

6. The bill posts to NetSuite when you want it to. By default the vendor bill is written after the final approver, with the PDF linked and an audit memo of who approved what. With Sync on First Approval, the bill posts after the first approver so AP aging and location P&Ls are current while later approvers review; their edits update the NetSuite record. The post takes 10 to 15 seconds, with no batch upload.

7. POs and credits follow NetSuite's own objects. Open NetSuite purchase orders sync in; bill lines match to PO lines, many to many and partially; on approval the PO is received and billed and an item receipt is created in NetSuite. Credit memos are read like bills, posted as negative vendor bills, and applied in a payment batch so the remittance shows the credit. Multi-currency bills post in the bill's currency.

8. Payment is a separate authorization. Bill approval says the bill is valid and coded; payment authorization says who releases funds, from which subsidiary's bank account, and when. Each subsidiary pays from its own account. Payments are made by ACH or check from MakersHub and the payment record posts to NetSuite. A payment made in NetSuite marks the bill paid in MakersHub. Sync errors, such as a closed period or a missing tax nexus on a subsidiary, show on the bill with their reason.

NetSuite specifics

Sandbox first. Most NetSuite companies connect a sandbox, run live bills through it for a few weeks, and switch the production token when the field mapping is settled. A sandbox refresh wipes the integration role and token, so they are recreated after a refresh.

Proof

A ten-location restaurant group in the UK, about 2,000 bills a month on NetSuite and two years on an AP tool that could not automate the Location field, saw ship-to-to-Location rules, stacked approvals by Location and amount, consolidated line sync and Sync on First Approval in one session.

Its finance lead on the first-approval sync: 

"That's a feature that I've been looking for in every call that I've been doing. A lot of people are like, no, don't do that." 

And:

 "I like the approval-to-pay feature because that's been a hurdle that I've been coming up against a lot, making sure that NetSuite is as accurate as possible at any moment in time."

A multi-branch smart-home design and installation company on NetSuite, about 2,000 bills a month and 80 percent PO-backed, with a few hundred bills a month failing to sync from its current tool because the Location field was missing, watched a six-page invoice match line by line to its POs with the NetSuite receipt status visible in the match screen: 

"We don't have that functionality. It doesn't exist." On the remittance a vendor receives: "That's a great remittance."

A senior-living operator across six states, about 1,000 bills a month and a third of them utilities with five to twenty Locations under one account, is running MakersHub in a NetSuite sandbox with its own allocation custom fields pulled in as native-list fields and about fifty line-distribution templates. Its AP manager, asking for rules on the combination of vendor, entity and coding, was shown that combination rules are unlimited.

What it doesn't do

Purchase orders are created in NetSuite today, and MakersHub matches against them; PO creation inside MakersHub is on the roadmap. MakersHub creates the item receipt when a bill is approved against a PO rather than matching against a receipt your warehouse already entered.

Payments fund from a US bank account; a UK or Canadian subsidiary approves and codes in MakersHub and releases payment from NetSuite today, with the two-way sync marking the bill paid. And NetSuite's own prerequisites still apply: a subsidiary needs its tax nexus and bank account set, and a bill into a closed period is held with a sync error that names the reason.

Frequently asked questions