An accounting manager at a mid-size company runs payroll and then spends an hour manually correcting the general ledger export from ADP before it can be imported into their accounting system — because the G/L mapping in ADP is hardcoded at the backend, can't be adjusted without a support ticket, and produces conflicting entries that don't match the chart of accounts they've built over years.
This is one of the most specific and recurring complaints in the dataset: users explicitly say the G/L interface is 'hardcoded at the backend' and that they'd need flexibility 'as some entries may be conflicting,' and that 'mapping on the G/L interface' needs to be easier to work with. It's not vague UI frustration — it's a concrete data transformation problem that happens every single pay period.
The reason this hasn't been fixed inside ADP is structural. G/L mapping flexibility requires ADP to support an essentially unlimited number of chart-of-accounts structures across all of their customers — every company organizes accounts differently. Building that inside ADP means supporting it forever, for every customer tier, at ADP's internal development pace. It's easier for ADP to hardcode a reasonable default and let accountants adapt to it than to build a fully flexible mapping layer.
The accountant who suffers through this every two weeks is not the person who bought ADP. They have no vendor relationship to escalate through. So they build manual Excel corrections and live with it — until someone offers them a way out.
This is a business because the problem recurs on every payroll cycle, the cost is measurable (manual correction time per run, plus the error risk of manual journal adjustments), and the buyer — a controller or accounting manager — is exactly the kind of person who will pay for a tool that saves them from a recurring, auditable, error-prone manual process.
What to build
Build a web app that ingests ADP's standard payroll G/L export file, presents a visual mapping interface where accountants define rules to remap cost centers, account codes, and department splits to match their own chart of accounts, and outputs a corrected import file formatted for QuickBooks, Sage, NetSuite, or a custom CSV — with the mapping rules saved and reapplied automatically every pay period.
Where to start
Launch specifically for companies running ADP Workforce Now alongside QuickBooks Online, where the G/L mismatch is most common and the accounting team is small enough to feel the manual correction pain directly — that's the tightest fit between the problem and someone willing to pay $50–100/month to make it go away.
The hard part
The hardest early problem is supporting the format variations in ADP's G/L export across different subscription tiers and configurations — without access to a broad sample of real export files, the mapping engine will break on edge cases for the first several customers.
How it makes money
Flat monthly fee per company (not per seat, since it's used by one or two people) — around $79–149/month depending on payroll frequency and number of entities, with a one-time setup fee for custom mapping configurations.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Core HR.
More ideas in Core HR