HRMS for the US region

Frappe HR
1

Hey folks,

I’m part of the Frappe team, and we’re currently working on bridging the gap in our HRMS to make it truly usable in the US, right out of the box. To do this well, we’d love to hear directly from people who are already using it (or have tried using it) in the US.

If you’re based in the US and open to sharing your perspective, I’d be happy to connect. We want to understand:

  • What’s missing today?
  • Where do you face friction in day-to-day use?
  • What features or compliance requirements are absolutely essential for the US market?

Your input will directly shape what we build next, and help us make HRMS a stronger product for everyone.

Would anyone here be willing to hop on a quick call or chat? feel free to book a slot here - https://calendar.app.google/KyxvsQhvSixEimEr8

2

@tejas There are a couple of really big missing pieces in the payroll module from my perspective as a small US-based business related to taxation.

  1. You may want to take a look at this very long thread starting here. It describes the lack of any way to reference Gross Year to Date pay prior to the current payroll run in a formula. This is crucial because there are several taxes that have YTD thresholds in them.

  2. In most of the US, there is a need for two Income Tax slabs instead of just one because income is taxed similarly at the federal and state level. Frappe HR currently only allows one tax slab. That means most of us in the US have to define complicated custom forumlae instead of using tax slabs. Please reference this thread and this github issue.

I’m open to discussing further in a call/chat if you think that would be helpful.

1 Like
3

In our company we’re trying to deploy hrms in our kubernetes cluster However we’re facing difficulties at finding a clear documentation.

4

why kubernetes?

5

@tejas We successfully implemented Payroll for a US client using the existing Payroll module, with a few customizations to make it functional for their needs. I can walk you through our implementation to give you an idea of the approach. There may still be gaps that other community members can help refine, but the solution has been in use by the client for last few months now.

6

In addition to what @trustedcomputer mentioned/linked, here are some areas that need improvement.

As mentioned, the feature request for allowing multiple income tax slabs would be great. I think this can further be enhanced as to how we “assign” the tax slab. I think it would be helpful to be able to use the tax slab like we use variables/components. We don’t want to “blindly” apply the tax to “gross income”. There are other tax jurisdictions or tax authorities that have more complex computations. If we could “call” or “assign” the tax slab inside a formula, that would give great flexibility.

I also think the limitation of only two types of Salary Components is not sufficient. Consider Employer Contributions and Employer Taxes. While we can use the existing system for these types of components, it’s not straightforward. See this thread for reference. You can also search “employer contributions” for others.

In the above mentioned “mega thread”, I think we can confirm there is a bug in the use of condition + formula. If they are not intented to work together, when filling one out, the other should be visibly disabled or there should be a note stating that they can’t be used together. We should be able to use both condition and formula, but it does not work.

Also discussed in the “mega thread”… Year To Date Gross Pay calculation is a sticking point. I understand it’s a catch-22, how do we generate formulas considering YTD_gross_pay, when the current period’s pay is not submitted yet. Saving the Salary Slip then Submitting the Salary Slip changes the values. As mentioned this makes it impossible to verify the amounts before submitting. This also makes “testing” salary components difficult. There are two built-in tests, but they are inadequet and behave differently.

  1. In Salary Structure Assignment there is a feature in the actions menu “Preview Salary Slip”. This only generates a preview of the first salary slip for the year. This is not useful to test components that rely on YTD numbers.
  2. In Salary Structure, there is a feature in the actions menu, “Preview Salary Slip”. This generates a preview for the next (or current) pay period. This is great if the YTD_gross is within the range I’d like to test.
    What’s really needed is a fully capable test where the user can input fictitious numbers for ‘pay_period/date’, ‘ytd_gross’, etc, to accurately test the Salary Components. We tried creating such a test, but with the validations used in HRMS, we haven’t been able to replicate the behavior.

In the USA, there are many tax jurisdictions, employee benefit types, etc. I think we should start by perfecting Federal Income tax, as that’s the low hanging fruit. Take a look at the W4 Form that employees fill out to determine their tax withholdings. How nice would it be to have a form in HRMS that captures the values and builds a Salary Component Deduction. I’ve built something outside of ERPNext that considers these values, and builds a complex formula using other Salary Components, including statistical components. Again, it’s not easy to test them (without going through a long process of running a test payroll run).

Better documentation on how Salary Components work, and how/when YTD values are calculated, would be a great help. Some of this seems mysterious, especially using conditions + formulas.

Other areas where I’ve struggled are related to the limitations within the formula. We can’t use important functions like MIN, MAX, and more. I’m sure blocking their use is for security reasons, but it is severely limiting (makes for much more complex formulas).

7

What do you suggest?

8

Hi,

Great to see you’re looking into this. Over the last year or two, HRMS payroll has actually become much less usable with US payroll, so I’m glad there’s interest to reverse that trend.

My 2c:

  • As mentioned by others, Tax Slabs should be associated to Salary Components, not Salary Structure Assignments. A typical US salary slip has multiple components based on marginal brackets. It is not currently possible to express this without brittle hacks.
  • Salary Slip Deductions should work with payable accounts. At present, it is only possible to make the single payroll payable account work this way. Other deductions don’t work with party-based accounting.
  • The relationship between Salary Structures and Salary Structure Components should be refactored to eliminate data redundancy. For example, formula based components store calculation details in both the Salary Structure document and the Salary Structure Component document, and it is structurally ambiguous which is being read.

Common requests that, in my opinion, shouldn’t be implemented:

  • Don’t add new component types. I understand that this is a convenience that people want, but it will create more ambiguity than benefit. Earnings and Deductions have clear, well-understood, direct correspondences to accounting entries. Things like Employer Contributions do not.
  • Make formulas do less, not more. US jurisdictions often need calculated values like gross_year_to_date to determine earnings and deductions, but there is no safe way to make these values available to formulas without creating circular references. These values need to be applied at the Salary Slip level, not the Component level. Clear error messages should be thrown if people try to use them in formulas.

Thanks again for the work on this! If I can clarify anything, please let me know.

9

Thank you folks for sharing your thoughts here, i’m gonna go over these and set up some calls with y’all. Looking forward, thank you!