One company, many brands, one invoicing platform.
A growing number of Invoiced.com users run multiple brands under one corporate umbrella. Same parent company, same AR team, same Invoiced instance — but customers know each brand by its own name, logo, email domain, and reply-to address. The standard Invoiced setup assumes one brand per account, which works fine until the first customer replies to a Brand A invoice and the email lands in Brand B's inbox.
The predictable workarounds are all ugly: spin up separate Invoiced accounts per brand (multiplies cost + fragments AR ops), or accept that customer replies go to the wrong place and sort them manually every day.
Customers get confused when invoice and response emails come from different brand addresses. Sales reps get cross-branded replies. AR ops struggle to tell which brand a response belongs to. Invoiced's standard setup uses a single SMTP identity — multi-brand operators need dynamic routing that lives outside the platform.
Multi-brand SMTP delivery for Invoiced.
Rubi built a dynamic multi-brand SMTP routing layer that sits in front of Invoiced and handles brand selection per-invoice based on business rules — sales rep, customer segment, product line, or any other Q360/Invoiced attribute. The right brand goes on the invoice, the right reply-to address is used, and inbound replies get routed back to the correct Invoiced message thread.
Each customer sees the brand they expect. Every reply lands in the right thread. One Invoiced instance does the work.
What the system does.
- Multi-brand sending — invoices go out from the right branded email address, with the right display name, domain, logo, and reply-to
- Centralized response management — inbound replies to any brand's address route back to the original Invoiced message thread so AR ops sees the conversation in context
- Intelligent brand selection — rules engine picks the brand based on sales rep, customer type, product line, invoice content, or any other attribute you configure
- Brand consistency — each brand has its own email template, styling, footer, and compliance disclaimers so customers never see mixed-brand messaging
- Scalable architecture — adding a new brand is a configuration change, not a new Invoiced account; supports unlimited brands and complex routing logic
Implementation.
- Initial SMTP configuration for each brand — dedicated sending identities with proper DKIM/SPF/DMARC so deliverability stays high across every brand
- Brand-specific email templates — one template per brand, configurable independently for subject lines, headers, footers, CTAs, and styling
- Routing logic framework — we codify your brand-selection rules (sales rep maps to brand, customer tag maps to brand, whatever your business logic is)
- Invoiced integration layer — the service sits between Invoiced and the outbound mail, intercepting invoice email events and applying brand selection before send
- Reply aggregation — inbound email parsing routes replies to the correct Invoiced message thread via their API
- Testing across all brands — we run full end-to-end validation for every brand before going live, including reply flow testing
Who benefits most.
- Holding companies with multiple operating brands on one financial backbone
- Franchise-model businesses where each franchisee has a distinct customer-facing brand but AR is managed centrally
- Acquisitive companies that have rolled up several smaller firms and want to preserve brand identities without maintaining parallel invoicing stacks
- Product-line-branded businesses where different product lines have different brand voices (e.g. premium vs value tiers)
Frequently asked questions.
Yes — the SMTP routing layer sits outside Invoiced, so it works with any Invoiced subscription tier. We just need API access to read invoice events and write reply threads.
Supported. Different brands can have different payment gateway identities (different Stripe accounts, different ACH settings) and the routing rules apply to payment emails too.
Brand additions are usually a 1-2 day job — register the new sending identity, configure SPF/DKIM/DMARC, add the template, and extend the routing rules. The core integration doesn't need to change.