How do I deal with discounts/refunds and a payment gateway to achieve accurate reporting for accounting? First off, this seems like a fairly basic function required for ecommerce. 

I was presented with a question today:


  "Will our new website give reporting so accounting can be done from within the website?"


The answer: "Yes! With Commerce Reporting module and Views."

Then came the followup question:


  "Great! So we will be able to add partial refunds, full refunds and discounts to existing orders within the site, have our payment gateway (PayPal) receive the discount/refund requests and have all of this show up in our reporting exports?"


The answer to that: "UMMMMMMM........"

Simple example: Customer purchases two items. Item #2 was a mistake. Customer requests a refund via good old fashioned email. We are presented with a question: Does the refund get issued from within Drupal Commerce or within the payment gateway?

What are the solutions for dealing with this?

Does the company still have to rely on the payment gateway (and its ever-changing, unstable export features) for reporting? If so, how does Drupal account for any changes made to an order (i.e. refunds, manual discounts)?

If not, how do I set up Drupal Commerce to get the reporting accurate to include refunds and any line item price corrections?
Step 1 - Enable Commerce RMA
First of all, you need to get something in place to enable the tracking/registration of such refund requests within the Drupal Commerce ecosystem. For that, the Commerce Return Merchandise Authorization module appears to be the best alternative available today. Some more details about this module (from its project page):

This module aims to extend Drupal Commerce with the Return Merchandise Authorization functionality. It's built on top of the nice Entity API library and using its own Entity Type (CommerceReturn).
Feature list:

Exposes a return of goods workflow on customer side.
Ability to separate products that can and cannot be returned
Ability to specify a return period, after which the ability to create an RMA is not available.
Provide an Admin UI to manage customer returns. Admin can remove or add product and change the prices of returned product.
Ability to customize the customer reasons on both product and product type levels.


Step 2 - Create custom Rules reacting to Rules Events about a CommerceReturn
By using the Commerce Return Merchandise Authorization module, you'll get the CommerceReturn entity types available. And because of those entity types, it opens up all sorts of custom business logic you may want to implement by using the Rules module. That will allow you to build custom rules that react on the typical entity-related Rules Events, such as:

After deleting a CommerceReturn.
After saving a new CommerceReturn.
After updating an existing CommerceReturn.
Before saving a CommerceReturn.

Step 3 - Create custom Views about CommerceReturn entities
As per those CommerceReturn entities, you also get out-of-the-box reporting (and even charting ...) capabilites by simply using the Views module. So for anything that is not already covered by Commerce Reporting, just create the required custom Views.
Step 4 - Create work-arounds for payment gateway limitations
I'm not aware of any solutions to also automagically take care of the payment gateway processing for such refunds. Especially because I think that there is no way to refund part of a transaction.
However, if you have the Rules module available (see above), you might create custom rules with Rules Actions that (eg) transform such CommerceReturn entities in (e.g.) User Points (piece of cake), so that they can be used to get discounts on future transactions.
Summary
The above is not a perfect/complete solution, but at least an improvement as compared to the  &quot;requests of a refund via good old fashioned email&quot; (as in your question). Actually it would at least keep track of such outstanding refunds to be processed.
PS: I'm assuming this is about D7.