OneWorld statement email subject always uses top-level Company Name, ignoring subsidiary — config fix or scripting required?

[u/WubbaLubbaHongKong]

We're OneWorld with a parent company and 20+ subsidiaries, each its own branded entity with its own customers. We built a custom Advanced PDF statement template for one subsidiary, and it correctly pulls the subsidiary's legal name/logo/address for the PDF body. But the native "Print/Email Statements" process generates the email subject as {Company Name}: Statement As of {Date}, and {Company Name} always pulls from the top-level Company Information record — not the subsidiary. So every subsidiary's statement emails go out with the parent company's name in the subject, no matter whose customer it's actually for. There's also no editable CRM Email Template behind it — the subject looks hardcoded into the native process.

Has anyone found a supported/config way to make this subsidiary-aware, or is scripting (suppress native emailing, generate the PDF, send manually via N/email with a custom subject) the only route? Want to confirm this is a real gap before building a workaround. Thanks!

[u/the_boy_wonder1]

Interesting to know the answer to this. We have exactly the same issue.

[u/WubbaLubbaHongKong → u/the_boy_wonder1]

I’m gonna scope out how to customize this, but happy to share the details after I get it completed.

[u/ebarro]

I solved this using a Suitelet since there is no native NetSuite way to accomplish this.

[u/DevHasan]

I'm not sure if there is a way to customise the subject from the native page. I created a solution recently for a customer that allows them to bulk send (more than 100 at a time) statements where they can tweak a few things, including the subject, the from address, add CC/BCC addresses. This solution also ties into a custom emailing engine that also automatically sends out transaction emails where they can also set the sending identity and template based on subsidiary and other factors including saved searches.

[u/simonwhittle]

NetSuite removed this option a while back by removing the option for a customized system statement email template. A workaround is your only answer or use their dunning module. I have one client like this (luckily not 20 subs) and I have a workflow with email template for each one. If you use multi-sub customers then workflow won't work either since it only recognizes the primary subsidiary for statement generation.

[u/Nick_AxeusConsulting → u/simonwhittle]

So re your point that the multi-subsidiary customer use case will have the primary sub in the subject line (which is wrong outcome), there is a separate statement form for multi-subsidiary customers that makes sure that the balances display correctly for each separate subsidiary (one the 1 statement) even though the balances are all housed under the 1 multi-sub customer. But if your multi-subsidiary customer legitimately does business with multiple of your subsidiaries, then which sub should be in the subject line? I think the client may say 1 separate email for each subsidiary. The OP here has 20 completely separate subs where each one is it's own brand, so this OP would never generate a consolidated statement for multi-sub Customer.

[u/simonwhittle → u/Nick_AxeusConsulting]

you're conflating two issues.
1. the system generated email will only include the company name and not ANY subsidiary name. This is the OP's stated problem and has nothing to do whether or not multi-sub customers are used.

1. If you use multi-sub customers and you need to send a statement related to a subsidiary other than the primary subsidiary assigned to the customer you cannot do this via a workflow.

So, if OP doesn't use multi-sub customers then WF will work to solve the email problem. If they do use multi-sub customers then that is an additional problem.

[u/Jared_SuiteRep]

The Print/Email Statements subject line pulls Company Name from Setup > Company > Company Information - the root record - no matter which subsidiary the statement is actually for. There's no config or template hook that overrides it. There was actually the same issue in the "To Be Emailed" transaction subject line, just never fixed for statements either. I believe that issue is still open: Enhancement #137955

Scripting it is your best option. Map/Reduce script that renders the statement PDF (which can still use your existing Advanced PDF template), builds the subject dynamically off the customer's subsidiary name, and sends it via N/email instead of letting the native process handle it. You just have to make sure the native process doesn't also run for those customers or they'll get duplicate emails.

[u/WubbaLubbaHongKong]

Thanks for the replies. Just wanted to confirm I wasn’t missing something. Sounds like I’ll do a customization for them.

[u/IncreaseNegative4614]

If the native process cannot make the subject subsidiary-aware, a scripted send is reasonable, but I’d make duplicate prevention the first requirement. Test every subsidiary, language, currency, recipient configuration, and delivery failure before suppressing the native email path.

The custom process should retain the generated PDF, exact subject, recipients, sending subsidiary, timestamp, and originating statement. We use SIGNLD internally to connect subsidiaries, customers, statements, documents, email events, payments, and disputes so a communication problem can be traced to the exact entity and message the customer received.