How are companies supposed to track warranty costs in Field Service?

Like probably everybody else with warranty processing, we have a customization for it...but we went with subaccount changes rather than specific GL accounts.  It’s a lot cleaner to have Parts COGS be account 5045 and then have warranty be subaccount (in our world) 6100 while billable service is 6000.  

For sure. That’s one way we solutioned it previously for a specific client. Keep the COGS account but have a warranty subaccount. We then drove the default subaccount from a WARR order type. Still required moving parts/labor items from original to the WARR. 

How did you customize it if you don’t mind sharing? 

The customization is more about how we process (because we need to recognize revenue for the warranty work as well) than about the subaccount.  For the subaccount we do the same as you--we have some Warranty service order types that set the subaccount (which is stock functionality).

I actually think that the way we handle the processing of the warranty claims and the revenue is really elegant; happy to share the logic if anyone is interested.

I’d be interested in the logic. I’m thinking about customization at this point since there does not appear to be a clean approach using native functionality from what I can tell. 

For our logic, there’s two main parts.

1. Using specific service order types that plug in our “Warranty” subaccount.  It took some work to convince our finance team that Subaccount would work for them--in our old ERP, we had a pretty significant customization that did what Sean was originally discussing--funnel revenue and COGS to specific GL accounts for warranty.  But once they saw that they could roll up parts and labor sales together in one account, and then split it by subaccount for billable vs. warranty, they came around to the light.
   Now, there’s one obvious flaw with this--if there is a mix of warranty and billable on a service order, or if you aren’t sure what it’s going to be, you can’t change the order type after the fact.  For big dollar differences we’ll manually change the subaccount before invoicing, but for the most part these are small dollar differences that don’t impact the financials materially.
   We have considered (but decided not to do it since the differences haven’t been material) having our customization (which I discuss below) change the subaccount if we tag a line as warranty and it isn’t in the warranty subaccount.
2. The customization is all about warranty processing, particularly for revenue and filing claims with vendors.  We have two custom values on the service order line, one for the warranty vendor and one for the claim sequence.  We could probably do without warranty vendor if we were better at making sure our Target Equipment records had vendor and warranty detail.  Claim sequence is there just in case we determine that we need to file two separate claims with the vendor on the same service order.
   The team tags a line with the warranty vendor (Claim sequence defaults to “1”).  This triggers setting a 100% discount on the line item, and updating the unit price to the current vendor price for the item for the warranty vendor (we set this to be the reimbursement value--we do separate our warranty vendor record from the vendor that we purchase material from).  This way, we know within the service order what the revenue will be, but it’s 100% discounted so the customer is not billed.  COGS doesn’t get impacted by the customization at all.
   When the service order is invoiced, there is a COGS hit but no revenue recognized.  Instead, we then generate warranty claims (with a separate scheduled process that reviews all of the service order invoices for the day).  The warranty claim itself is a PO Return Receipt with a little extra data--but the logic is primarily stock.  We tell the system that we are returning a non stock item to the vendor for each line on the service order.  The cost is the pre-discounted price of the item (part or labor).  The (expense) Account value and subaccount are copied from the sales account and sub values on the service order line, and the accrual account is our Warranty AR account.  In the GL, this causes the revenue account to get credited and the AR account to get debited.  
   Other than the Process Warranty screen filling in a few values on the PO Return Receipt, the processing is all stock.  The return receipt itself results in the appropriate debits and credits, and when the vendor pays us the payment credits the warranty AR account as part of the Debit Adjustment entry.

​@lairdtim thanks for sharing! 

We’ve solutioned a similar warranty claim “return” process as you described in your second bullet point. 

I like marking items for warranty at the line item level with the service order. 

I have ideas on potentially developing customization that supports two fundamental warranty scenarios:

• Covering service items (parts, labor, etc.) under company warranty > rerouting the GL coding to warranty related expenses accounts 
• Vendor or Third-party warranty claims > similar to how you described, I’d consider some sort of “mark for warranty claim” workflow that supports the costing and initiates the claim process similar to “mark for PO” but using PO Return receipts.

There’s more to that, but at high-level that’s what I’m thinking…