We build the sync layer HR runs on.
OmniSync HR is a product company built on a narrow observation: between a company's global HR system and its local payroll system sits a job nobody was hired to do.
Multinationals with a Philippine or APAC entity run two systems of record — a global HRIS that holds the truth about people, and a local payroll system that turns that truth into pay. The vendors on both sides are excellent. Neither is responsible for the space between them. So at most companies, that space is staffed the only way an unowned job ever gets staffed: someone — on no org chart, in no job description — re-keys every hire, transfer, salary change, and resignation from one system into the other, cutoff after cutoff. At most companies, the sync layer is a person. The work is invisible every month it goes right and very visible the month it doesn't — the month one record misses the trip, and someone who resigned keeps getting paid, or someone who started doesn't get paid at all.
Hiring more careful people won't fix that, because carefulness was never the problem. It's an infrastructure gap. The layer that should connect these systems was never anyone's product: global vendors stop at their API, local vendors stop at their borders, and integration firms build the bridge once and move to the next project. The market's other answer has been to sell the re-keyer a toolkit — as if what was missing was a license. OmniSync HR was started to own the gap itself: to build the sync layer between global HR and PH/APAC payroll as a product — run, watched, and measured, every cutoff — and make the unofficial job official: owned by engineers, priced in public, measured by a number we can miss.
If someone on your team recognizes this job — because they're the one doing it — this page was written for them. The rest of it tells you what kind of company that observation makes us, then points you at the pages where everything we promise is written down with a number attached — because an About page's adjectives bind nobody.
One problem, solved completely ¶
Start with the question a vendor reviewer actually brings to an About page: why should a company you've never heard of sit between Workday and your payroll?
Because it was built for that seam — and for nothing else. The integration market rewards breadth: a catalog with a thousand connectors demos better than a page with two, and a logo wall photographs better than an SLA. We think that market is optimized for the wrong moment — the sales call instead of the payroll cutoff. Up close, a connector built to be one of a thousand moves fields. It doesn't know your payroll calendar exists, can't say which of two disagreeing systems is right, and treats a rejected termination record like any other log line — and the economics of a thousand connectors leave the vendor little room to know any one of them deeply. Breadth is honestly useful for problems where every connection is worth a little. Payroll isn't one of those problems: it either holds at cutoff or it doesn't, because payroll doesn't average out.
So we made the opposite bet, and we made it the whole business: OmniSync HR does exactly one thing. One problem solved completely is worth more than a thousand problems solved to a demo. No consulting arm, no sprawling catalog play, no adjacent product lines — the syncs are the whole business. That structure is the point: a large generalist can afford for your integration to be its thousandth priority; we can't. And "omni" was never a promise of breadth — it's a promise of coverage in depth: every record that should move, moved; every record that couldn't, held visibly with a reason. (If total focus makes you ask what happens to you if the focused business stumbles, that question has its own section: Will we be here in three years?)
Focus is also why the rest of this site can be as specific as it is. A published price, a measured SLA, a closed exclusions list are only possible when the service is one deliberately narrow thing. Every layer a shallow connector leaves out — validation before anything writes, quarantine with reasons a payroll officer can act on, a parallel run before go-live, engineers who operate what they built — exists here because we don't have nine hundred and ninety-nine other problems to be adequate at. It's why our integrations page is short (→ Why this list is short), and why the list grows the only way depth allows: one pair at a time.
Why the Philippines — and why "specialist" is the strategy ¶
Because "global coverage" is how this problem stays unsolved. Most integration vendors support the Philippines the way an atlas supports a city — technically present, no help when you're standing in it. Payroll here isn't a locale setting. Pay runs semi-monthly, so cutoff arrives twenty-four times a year, not twelve. Thirteenth-month pay, leave conversions, government ID numbers — everyday furniture here, not the exotic request a generalist's roadmap gets to someday. Four separate agencies each run their own filing calendar. And cutoff runs on Philippine time — which is why our SLA defines a business day as a Philippine business day, and our support hours are quoted in PHT rather than translated from another continent's morning.
So we went the other way: one corridor — a global HRIS like Workday on one side, local systems like Sprout on the other — worked completely. That focus compounds in a way coverage can't: the code tables, the statutory quirks, the cutoff calendars aren't things a license key can hold — they accumulate in a platform and the team that runs it, and only if that team stays on one corridor long enough to learn it. A specialist accumulates them; a generalist spreads the same learning across dozens of geographies until it's too thin to matter in any one of them. A five-hundred-connector catalog is impressive right up until you ask how many entries the vendor will put an SLA behind — here, a pair isn't listed until the answer is yes.
→ Why the list is short (Integrations)
Being a specialist also draws a boundary we keep: if your problem isn't this corridor, we're not your vendor. A specialist who never says "not us" is just a generalist with a niche on the homepage. Specialist isn't the modest word on this page. It's the whole strategy.
Three kinds of company will offer to fix this. Look at how each is built. ¶
Several kinds of company have sold fixes for the problem OmniSync HR works on — two HR systems that must agree at every payroll cutoff — for years. Before you read what any vendor says about itself, us included, it's worth looking at how each one is built, because a company's structure predicts its behavior better than its brochure does.
Platform vendors sell licenses. The connector catalog is the product, so the catalog grows — hundreds of systems wide — and the operating burden ships to you with the login. Nothing in that company is paid to notice that your Tuesday sync failed.
Systems integrators sell projects. They're built to staff up, deliver, and roll off — that isn't a flaw, it's the business model working as designed. But payroll cutoff never rolls off, and forever isn't a project.
Unified-API startups sell developer infrastructure. Genuinely useful — if you have engineers to put on it. Their customer is your engineering team, which is exactly the team this problem shouldn't need.
And because "Philippine vendor + HR + payroll" pattern-matches fast, two more boxes we don't fit.
Not a BPO: we don't take over your payroll, your process, or your people — your team keeps every decision it makes today; it just stops re-keying data between systems.
Not a staffing shop: nobody here is billed to you by the hour — setup is a fixed quote, the monthly fee is flat per integration pair — no day rates, no metered hours.
None of these companies is badly run. Each one behaves precisely the way its revenue tells it to. So when we say OmniSync HR is built differently, we don't mean the culture page — we mean the revenue: a flat monthly fee for syncs that succeed, per integration pair, with service credits that apply themselves when they don't (→ Read the SLA). What that fee structure trains this company to do has its own section below (→ How we bill). If your vendor-management system insists on a box: managed software service, annual term, priced per integration pair.
What "product company" means when the product runs 24/7 ¶
"Product company" is doing specific work on this page, so here is what we mean by it — and what we don't.
We don't mean you download something. The product is a sync platform that runs on our infrastructure, operated by the engineers who build it — you get the dashboard, the alerts, and the reconciliation reports; we get the pager. If your definition of product requires that we hand you a login and wish you luck, then no, we fail that definition — on purpose. A sync layer nobody is watching isn't a product yet. It's a liability with a UI.
What we do mean is how the thing is built and sold. Every integration we ship runs on one platform — the same validation pipeline, the same quarantine machinery, the same dashboard — not a bespoke build that happens to share a logo. When we improve how the platform handles a vendor's API quirk, every integration on that connector gets the fix. And the commercial shape follows the engineering shape: a published price instead of a day rate, an SLA with service credits instead of best effort, a scope fixed in a signed document instead of a meter (→ See pricing).
The structure inside the company matches. You've likely met the vendor that is really three companies wearing one logo: a sales team that promises, a delivery team that builds, a support team that inherits — and every handoff between them loses information, until the person who eventually answers your ticket is the person who knows your integration least. OmniSync HR is structured so those handoffs don't exist. Scoping produces a fixed quote before the work starts — published starting prices, one call, a number that holds. The people who build your integration are the people who operate it — there is no "transition to support" milestone, no delivery-partner network, no subcontracted build team (→ Who reads your ticket, on the SLA page). And the people who operate it are the people the SLA binds: when a month misses 99.5%, the credit lands on the same team that can make next month different.
That isn't a staffing accident we'll outgrow. It's the design — the org chart the product requires: a product company that operates its product. A vendor's org chart usually tells you who to escalate to; ours tells you something more useful — there is nobody else the problem can belong to.
You can read our future behavior in how we bill ¶
A vendor's brochure tells you what it intends. Its fee structure tells you what it will actually do — because a fee structure is the one promise that enforces itself. Day rates make change orders a revenue line, so changes get found. Per-ticket fees make your questions billable, so problems grow quietly before they're reported. License sales make the signature the finish line, so month nine belongs to nobody.
We priced OmniSync HR to point the other way, and each choice trains the company it pays for:
- A flat monthly fee, per integration pair. No metered hours, no per-ticket billing — a question, a re-run, a vendor-release retest all add the same amount to your invoice: nothing. Inside that fee, the only work that improves our margin is work that prevents problems — though a flat fee alone would also reward neglect, which is what the next line is for.
- Service credits that apply themselves. A month below the SLA costs us 10, 25, or 50% of that month's fee, automatically — no claim form on your side, no discretion on ours (→ Service credits, on the SLA page). A failed month isn't an apology here; it's a line item.
- The meter starts when your sync does. The monthly fee begins at go-live, not at signing, and half the setup fee is only ever invoiced once the parallel run proves the integration against a real payroll cycle (→ When you pay, on the Pricing page). Until your integration works, most of the price hasn't even been invoiced.
- Vendor churn is pre-paid. When Workday ships a release or a local vendor changes an API, the connector work is already inside the monthly fee — there is no version of that event that produces an invoice.
A firm billing day rates earns most in the months your integration struggles; we earn our fee in the months nothing needed your attention. Our best month and your best month are the same month. The numbers live on the Pricing page and the credit mechanics on the SLA page — this page only explains their shape: incentives are the part of a vendor relationship that still works when nobody's watching.
What we believe about software that touches payroll ¶
Positioning pages say "values." Payroll people check receipts. So here are ours — each one with the place on this site where it's already a commitment you can hold us to.
- An error message belongs to the person who has to fix it. If a record can't go to payroll, the explanation should name the record, the problem, and the fix — in the language of whoever is clearing exceptions before cutoff, not of the engineer who wrote the validator. In writing: plain-English quarantine, on every record, every run.
→ When a record is wrong (Product) - A vendor's number should be checkable by the customer. An SLA you can't verify is a slogan. Our sync-success rate is computed in your dashboard, from your own runs, using the same definition the contract uses.
→ How the number is measured (SLA & Support) - The people who build a thing should be on the hook for it. Integrations don't fail at the demo; they fail quietly, long after the kickoff deck is archived. So there is no handoff: the people who build your integration operate it.
→ You get a platform. We operate it. (Product) - Payroll's calendar outranks ours. Cutoff doesn't move because a vendor had a scheduling conflict. Implementation is planned around your cutoffs, and maintenance is scheduled outside your payroll windows — never on top of them.
→ How implementation works (How It Works) · Scheduled maintenance (SLA & Support) - "Not yet" beats getting caught. The price is on the pricing page, the limits are on the product page, and the security page says "not yet" where it's not yet. Trust built on checkable statements survives due diligence; the other kind doesn't.
→ What this page doesn't claim — yet (Security)
Built by the people who answer for it ¶
About pages usually answer "who are you?" with a photo wall. Here's a more useful answer. When your sync fails at 6 a.m., the alert doesn't go to a dispatch queue — it goes to the engineers who built and operate your integration. The same people read your support tickets, because we deliberately built no tier-1 layer to escalate past: the person who answers has seen your field mappings and knows which day your cutoff falls. The mechanics — hours, response times, Premium's payroll-window emergency line — are on the SLA page, in writing, where commitments belong (→ Who reads your ticket).
And here's the answer to the question behind the question. OmniSync HR is built and operated by the engineering team at Nago Tech, which has been building systems integrations for multinational law-industry clients since 2018 — across twelve markets, from China and Southeast Asia to the UK, Sweden, South Africa, and the UAE. Law firms are where confidentiality is set by professional privilege and deadlines are set by courts; two systems disagreeing there is never a shrug. That is the discipline this platform applies to payroll. The HR corridor is a new name for us, not a new job: making two systems of record agree across a border is what this team has done since 2018. There is no separation between the people making the promises on this site and the people who have to keep them at your next cutoff — the ones who wrote these pages are the ones who'll sit in your parallel run.
On a scoping call you'll meet the engineers directly — names, backgrounds, and the person who'd own your integration. Until then: the platform, the paper, and a company you can look up.
Will we be here in three years? ¶
Asked of a vendor whose name you just learned, it's the right question — so here is the answer we'd give across the table, in three parts, weakest last.
The first part is contractual, because early trust shouldn't have to be personal. The commercial terms are built so that believing in us is never a requirement: the monthly fee doesn't start until your sync is live; the second half of the setup fee is never invoiced if the parallel run can't be made to match; and you never have to prepay — under monthly billing the cash you've paid ahead is never more than the month you're in, and if this question is the one that brought you to this page, monthly is the billing to choose. A prepaid year carries a contract-defined termination right with a pro-rata refund — the trigger is chronic SLA failure, a clause you'd enforce against a company still standing. And any term ends, with notice, without an exit fee (→ the terms, on the Pricing page). Read those clauses as what they are: the weight a long corporate history would normally carry, moved into paper you can enforce.
The second part is structural — what happens to you if this business doesn't make it. Your employee records never lived only with us; they stay in your HRIS and your payroll system, which keep working on the day we don't. The field-mapping document — the complete, versioned blueprint of what moves, where, and under which rules — is signed and yours. Our access dies when you say so — the service accounts live in your systems (→ leaving, on the Security page). If OmniSync HR disappeared, you would stand exactly where you stood before us: back to the process you run today, holding a signed mapping document a successor would otherwise spend weeks reconstructing, plus months of reconciliation reports. That's a real cost, and we won't pretend it isn't. But it's a setback, not a hostage situation — choosing a new name here risks your time, never your data. We designed the exit before we designed the logo.
The third part is the one every About page offers, so we'll keep it short — though ours comes with a date you can check: we intend to be here, the business is shaped for it — one product, a recurring-revenue model, a problem that returns at every cutoff, forever — and the company behind it has been shipping integrations since 2018 (→ Built by the people who answer for it). But even that isn't the part to weigh most. Weigh the first two.
What's not on this page — and why ¶
An About page has standard furniture: the team photo grid, the founding-story timeline, the values list, the wall of logos. Ours doesn't — because none of that furniture is anything you can hold us to, and being held to things is what this site is built for.
- No team photo grid. A photo doesn't tell you who answers when a sync fails at payroll cutoff. That's printed where it's enforceable: the engineers who build your integration read your ticket, and answer for it at the next cutoff (→ Who reads your ticket, on the SLA page).
- No timeline. A milestone graphic describes a company's past. Your risk lives in its future months — and those are the ones already priced: 99.5% of scheduled syncs completing successfully, measured monthly, with service credits that apply automatically when we miss (→ The SLA, in full).
- No values list. No vendor has ever listed the opposite of "integrity." The beliefs above are our version — each one attached to a mechanism already live on this site, which is the only kind of values a reviewer can actually check.
- No badge wall, no analyst quadrant, no testimonials standing in for evidence. The Security page already prints the rule, and it governs this page too: nothing gets a badge before it has the paper behind it.
Furniture tells you how a company presents. Terms tell you what it does under pressure — and everything worth trusting us for is written where it costs us to break it.
Don't take our word for any of this ¶
An About page is the easiest page on any website to write, because nothing on it can be checked. And reference calls and logo slides — the way vendor risk usually gets retired — are other people's diligence, aggregated. So this site is built for the primary-source version instead: every load-bearing claim comes with a way to test it that doesn't depend on believing the person who wrote it.
| The claim | How you check it |
|---|---|
| The price is published | Setup, monthly, term, renewal — on the page, and so is what can move a quote. Hold the quote we send you against both. → Pricing |
| The SLA is real | Your dashboard computes the same monthly figure the service credits key off — the evidence lives on your screen, not ours. → How the SLA is measured |
| The exclusions won't swallow the SLA | The list is closed: six items, printed in full, no discretionary catch-all to hide behind. → SLA exclusions |
| The build actually works | The parallel run settles it: our output beside a real payroll cycle, differences flagged, and nothing writes to production until your team has compared them. → The parallel run |
| The security posture holds up | The page says where every claim stands, gaps first — and your questionnaire (SIG, CAIQ, or your own) comes back answered by engineers. → Security & compliance |
| The experience is real | The company behind the platform — Nago Tech, integrating systems for multinationals since 2018 — is checkable outside this website. → Who answers for it |
| The claims discipline is real | Our roadmap runs on a published rule — no status is ever promoted by announcement. This page is written to the same rule. → The roadmap |
| We're straight about fit | The one row you can't check from your desk. Book the scoping call and watch what happens when your stack doesn't fit. |
If you read only one, read the SLA — it's the page where missing our own number is priced.
One more thing, because a skeptic will think it anyway: this page isn't honest because we're virtuous. It's honest because dishonesty is a strategy we can't afford — every claim here is published, and the first exaggeration your procurement team catches is the last page of ours they read. That's not inspiring. It doesn't need to be: everything above stands or falls on its own check.
You've read about us. The call is about you.
Everything on this page is ours — the thesis, the way we run. The scoping call is the first conversation that's about your stack instead: which systems have to agree, what has to move between them, and where the manual work sits today. So bring the person most likely to say no — your security reviewer, your procurement lead, your hardest skeptic — and put any of this page to the test live. You get a fixed quote within a week, whether or not you buy, and the published terms you've been reading are the terms the quote is built on. We solve exactly one problem; if yours turns out to be a different one, the call ends with a straight answer, not a follow-up sequence.
Book a scoping callStill mid-diligence? The check-map above is a shorter route than this button.