Overview of MarginDriver Ecommerce Accounting

Overview of MarginDriver Ecommerce Accounting

MarginDriver is an accounting solution specifically designed to meet the needs of multi-channel ecommerce businesses. Unlike it's competitors, MarginDriver is not a connector, bridge or syncing app. Those solutions exist to match a settlement report from a marketplace or payment gateway to a bank deposit. This serves an important bookkeeping/accounting functionality to be sure, but it provides the seller with no value beyond time-saving and automation. 

MarginDriver recognizes that there is valuable data being passed from the marketplace or payment gateway to the general ledger that, if captured and properly organized, can be harvested for business intelligence that can fuel growth and profits. Therefore, MarginDriver endeavors to treat each ecommerce order as it's own profit center and calculate and present it's gross profit in real time. This process forms the foundation of MarginDriver's analytics tools and automated accounting functionality. The result is the only truly comprehensive ecommerce financial reporting and accounting solution available to today's sellers. 

The following is an overview how MarginDriver does it. 

Accessing Data and Calculating Gross Profit

Financial data for each ecommerce order is retrieved via API connections with MarginDriver's integrated source marketplaces and ecommerce platforms (collectively referred to within MarginDriver as "Sales Channels"). Data is retrieved as quickly as programmatically possible, subject to API throttling limits, usually within a few hours of the customer placing the order. 

Every order is accounted for as its own profit center on an accrual basis and presented in a sortable and filterable format in the MarginDriver Dashboard. 

The financial data used to calculate each order’s gross profit includes:
  1. product revenue and cost
  2. shipping revenue and cost
  3. marketplace commissions
  4. credit card surcharges
  5. FBA fulfillment fees
  6. currency conversion fees
    1. All currency data is converted into the user's desired display currency and currency conversion fees are accounted for where appropriate.

Real-Time Delivery

MarginDriver's Dashboard/So Far Today feature displays each order's gross profit with supporting detail at the bottom of the page within a few hours of the order being placed. (The one exception is shipping cost, which is generally unavailable until the order has actually been shipped. In order to provide the user with gross profit data in as near to real time as possible, an estimated shipping cost is used and displayed in orange until the actual shipping cost is available, at which time the actual value is populated in black.)

Manual Data Input (if necessary)

In some rare cases where data is not available through an API, the user will need to upload such data from a flat file. In such instances, the availability of gross profit reports will depend on the timing of the file upload by the user.  

Setup and Mapping of GL Accounts

Once a user has completed sales channel setup and established a connection between their MarginDriver and Quickbooks Online accounts, MarginDriver will automatically populate the user's QBO general ledger (GL) with the accounts needed to capture MarginDriver's automated month-end journal entries (JEs). These GL accounts include all of the applicable AR accounts for Amazon, Shopify, Walmart, eBay, PayPal and other payment gatways. 

The GL accounts established by MarginDriver will have account number followed by "-MD" to identify them as originating from MarginDriver. Within MarginDriver, these accounts can be viewed by visiting Settings > GL Account Settings. 

Matching Deposits with the Corresponding GL AR Account

Deposits made by third parties such as Amazon, Shopify Payments, Walmart, PayPal, etc. directly into the user’s bank account(s) are matched automatically to their respective general ledger AR accounts by MarginDriver. 

Clearing Account 1270 - Tracked Payment Gateways

Within a few hours after a deposit appears in the user’s bank account, MarginDriver transfers it as a credit into GL Account 1270-MD, a MarginDriver established GL clearing account. From there the deposit is matched to the appropriate sales channel and/or payment gateway and then automatically transferred as a credit to the matching GL AR account. 

There are certain payments/deposits for order revenue that cannot be tracked and therefore cannot be automatically matched with their appropriate order and AR account. Such payments include payments made viva manual transactions, checks, crypto, wire transfers, etc. These orders are all placed in AR accounts titled AR Other Gateways-MD and the payments for these orders must be manually matched by the user and placed into the corresponding AR Other Gateways-MD account. 

The user should never manually match a deposit with a MarginDriver AR account that is not an AR Other Gateways-MD account. This is because deposits that belong in any trackable AR accounts are automatically matched and transferred into the appropriate AR accounts. But AR Other Gateways-MD GL accounts are where the revenue less related fees (estimated amount due) is posted for these orders and therefore where the related deposits for such orders should be placed. 

Clearing Account 1280 - Untracked ("Other") Payment Gateways

If a user mistakenly places a deposit that belongs in an AR Other Gateways-MD account in a trackable MarginDriver AR account, the deposit will automatically be removed from the trackable AR account and placed in the MarginDriver GL Account 1280-MD, where it will sit until the user transfers it to the appropriate AR Other Gateways-MD GL account. The user should review the AR Account 1280-MD at the end of each month to see if there are any deposits credited to this account. If so, the user should manually transfer these deposits to their appropriate AR Other Gateways Account-MD.

Matching Individual Order Payments to the Corresponding Orders

This is a completely different process than the matching of deposits to the correct general ledger AR account discussed above. The matching of individual payments to their corresponding orders is addressed in detail in the discussion of Accounting > Accounts Receivable Order Tracking & Payment Reconciliation.

Fees

Sales channel fees are separated into either direct or indirect fees:

  1. Direct Fees

    1. Fees that can be directly attributed to individual orders which are included in the gross profit calculation for each order.
      1. product and shipping COGS
      2. marketplacec commissions
      3. FBA fulfillment fees
      4. other fees

  2. Indirect Fees

    1. Fees that cannot be directly attributed to individual orders.
      1. subscriptions and services that go to the benefit of the seller's entire account
      2. With respect to Amazon FBA specifically, indirect fees encompass costs related to inbound inventory transportation, storage and handling.
Indirect fees are allocated equally across all orders placed on a sales channel for the month that the indirect fees were incurred. The breakdown of all fees can be found in the Order Detail reports. 

Users have the option to include the indirect fees as part of the COGS for each order (where it is included in the gross profit calculation for each order), or the user can elect to have the indirect fees classified as operating costs. This setting can be found under Settings > User Profile. 

Accounting for Product COGS

Product costs can be populated either programmatically, depending upon the user's source data systems and their configuration, or via flat file upload. Regardless of the method of retrieval, it is the responsibility of the user to keep all product costs accurate and accessible. 

When the product COGS for the month is posted to the user’s GL with MarginDriver’s month-end journal entries, the amount is a debit to the respective sales channel’s product COGS account and a credit to the inventory account, reducing the amount of inventory in the user's GL by the cost of the products sold during the month. MarginDriver does not track or manage inventory levels; it only records the amount of inventory sold during the month using the product costs provided by the user.

Accounting for Shipping COGS

Shipping costs are accounted for as COGS in MarginDriver and therefore included in the gross profit calculation for each order. Like product costs, the availability and accuracy of shipping costs is the responsibility of the user.  MarginDriver integrates with several shipping software solutions to facilitate automated access to these values. Likewise, shipping and fulfillment fees for Amazon FBA orders are pulled directly from the Amazon API and matched to the appropriate orders. Alternatively, users can also populate shipping costs via flat file upload. 

When the shipping costs for the month are posted to the user’s GL with MarginDriver’s month-end journal entries, the amount is a debit to the respective sales channel’s shipping COGS account and a credit to a GL current liability account established by MarginDriver  called “AP Shipping Costs”.  It is recommended that the user also debit this account for the payments to shipping vendors. By doing this, an ongoing accounts payable balance will be created that reflects the amount owed to providers of shipping and fulfillment services.  

Refunds

MarginDriver also tracks the refunds issued on its users' integrated marketplaces and ecommerce platforms. Refunds reduce the user's gross profit in MarginDriver but the timing of issuance can be sporadic. So as not to disproportionately impact the gross profit on days that refunds happen to be issued, MarginDriver utilizes a calculated daily Refund Allowance similar to how some companies use an accounts receivable allowance. These companies often write off their uncollected accounts receivables once a year in December and use an AR allowance on a monthly basis to spread the cost of these annual AR write offs evenly across the twelve calendar month. 

MarginDriver follows a similar practice with respect to refunds, spreading their financial impact evenly across all the days in a given month.  A 28, 30 or 31-day moving average of actual refunds is used to create a month’s daily Refund Allowance which is applied to the day's gross profit instead of the actual refunds recorded for that day.  As a result, on the last day of the month (no matter if that month has 28, 30 or 31 days) the total actual refunds for the month will equal an accumulation of the daily refund allowance for the month.

Audit Trail

The financial results for each individual order can be accessed at Gross Profit Reports > Order Detail. The Order Detail feature provides users and accountants with a permanent record of each order’s financial data including gross profit and an audit trail to the data’s original source.

Monthly Gross Profit Statement

The gross profit and related financial data for all orders are accumulated by sales channel and displayed chronologically using the date each order was placed. The financial results for all orders in a month are summarized to establish that month’s gross profit statement which can be viewed at Gross Profit Reports > Gross Profit Statements. The monthly gross profit statement is then posted to the user’s general ledger via journal entries in the Close Month and Post to GL feature.

Balance Sheet Adjustments Included in Order Payments

The monthly Gross Profit Statement journal entries also include any balance sheet-related adjustments included in payments to users by various seller marketplaces/platforms such as Amazon. Shopify Payments and Walmart. Balance sheet transactions such as inventory adjustments, as well as loans and loan repayments, can increase or decrease payment made to sellers for sales activity. MarginDriver sorts through these adjustment and transfers them to the user's general ledger in a single journal entry. The one exception are adjustments to inventory which are placed in the user's GL inventory account.

Closing the Accounting Month

MarginDriver should be understood as a source of original data that is then transferred into the user's GL system. Therefore, once a month's gross profit is considered complete, the month is closed and the gross profit statement is transferred to the user's GL with the month-end JEs; no changes to the month's data are permitted once the month is closed. 

There may be occasions when the data is incorrect and corrections need to be made to data in a month that has been closed.  When such a situation occurs, MarginDriver allows the user to reopen the month by revisting that month's accounting tasks and reversing all journal entries for the month. Data can then be altered or added and the month can then be closed again.

    Article Categories