ERP
PowerGP Online
Connect your AI to PowerGP Online
Finance and accounting managers, operations and purchasing managers, and payroll and HR administrators run the business through Microsoft Dynamics GP, but the answers they need span companies, modules, and inquiry windows that GP treats as separate lookups. AI can answer those questions in seconds, but only if it respects Dynamics GP company boundaries and user permissions, and treats payroll and employee data as confidential.
Why it matters
Capabilities that matter most for PowerGP Online
01
Read-only GP tools for AI
42 read-only tools cover customers, vendors, GL, payables, receivables, sales, purchasing, inventory and payroll, so an AI client can look things up but cannot change a record.
02
One company at a time
Every question runs against the Dynamics GP company you name, so figures from one company are never mixed into another, and you can compare companies side by side when you ask.
03
Payroll data kept confidential
Payroll and employee tools are built for exception checks. The ready-made payroll prompts never print social security numbers, birthdays or home addresses.
03
Ready-made jobs from the app store
Thirteen prompts in the app store cover AR aging, cash needs, reorder risk and payroll audits, so teams start from a tested job instead of a blank chat.
05
GP beside your other systems
Cross-system prompts compare GP with Shopify, Stripe, Chargebee, Ramp, BigCommerce and WooCommerce, flagging mismatches without writing to either side.
Use cases
Example AI Use Cases for PowerGP Online
scenario
-
Buyers see what sells in BigCommerce but see stock and open purchase orders in Dynamics GP, so spotting the best sellers that are about to run out means adding up order lines by hand and looking each SKU up in a second system. Refunded lines get counted by mistake, and a SKU runs dry before anyone raises a reorder.
What popdock provides
--
Name a GP company and, if you like, how many days to look back and how many top SKUs to check. It reads recent BigCommerce orders, adds up units sold per SKU without the refunded lines, then looks up on hand and on order stock and open purchase orders for each top SKU in that company only. You get days of cover and next promised date per SKU, with low cover and no order due flagged. SKUs that are not in PowerGP Online are listed separately, the number of orders read is capped and stated, and nothing is changed in either system.
Business outcome
---
Buyers see which best sellers will run out before supply arrives, in one read-only report, without cross-checking two systems.
scenario
-
Web prices are set in BigCommerce while costs sit in Dynamics GP, so margins are worked out in a spreadsheet after exporting both. Products with thin or negative margins go live, and a web price that drifted from the GP price list is only noticed by accident.
What popdock provides
--
Give a GP company, a minimum margin percent and, optionally, a brand. It reads the BigCommerce products, looks up the current cost and price list for each SKU in that company and calculates margin on the price the customer pays. You get a table of products under the threshold and a second table where the web price differs from the GP list price by more than 5 percent. Products with no GP item or a zero cost are skipped and counted, rows in another currency are flagged rather than compared, and nothing is changed in either system.
Business outcome
---
Thin margin products and web prices that drifted from the GP price list are found before customers buy them.
scenario
-
BigCommerce shows one stock level and Dynamics GP shows another, and comparing them SKU by SKU means opening two screens. The store oversells when its level is above what GP holds, and stock sits unlisted when GP holds more than the store shows.
What popdock provides
--
Name a GP company and, optionally, a SKU and a GP site. It reads BigCommerce inventory levels, including variant SKUs, then reads quantity on hand and on order from PowerGP Online for each SKU, summing sites when none is named. You get a table sorted by the largest difference, with oversell risk and stock not listed online flagged. Store only SKUs are listed and continued past, products where the store does not track inventory are noted, a run without a SKU covers the first 50 products and says so, and nothing is changed.
Business outcome
---
Oversell risk and unlisted stock show up in one sorted comparison instead of a manual check across two systems.
scenario
-
When a customer calls, their orders are in BigCommerce and their balance and overdue invoices are in Dynamics GP, so support opens both and pieces the account together. With no shared id, the wrong customer is easy to pick, and a high overdue balance goes unnoticed while the customer keeps ordering.
What popdock provides
--
Give a customer name or email and a GP company. It finds the BigCommerce customer, reads their recent orders with totals and refunds, then finds the PowerGP Online customer by name and reads balance due and open items with days past due. You get identity in both systems, order history, GP standing and one line on any concern. If several customers match on either side it lists them and stops, the GP match is stated as a match by name and not a confirmed identity, and nothing is changed.
Business outcome
---
Support sees orders and account standing together, with the identity caveat stated, and answers the customer in one pass.
scenario
-
The web catalog and the Dynamics GP item master drift apart, and comparing them means exporting both into spreadsheets and matching SKUs by eye. Products go live with no GP item, items never reach the store, and web prices fall below GP cost without anyone noticing.
What popdock provides
--
Name a GP company and, optionally, how many records to read per side. It reads BigCommerce products and PowerGP Online items, matches SKU to item number ignoring case and spaces, and retries a missing SKU once before calling it missing. You get three lists: store products with no GP item, GP items with no store product, and matches where cost differs or the web price is below GP cost, with counts. If no SKU matches it says the systems appear to use different identifiers and stops, capped reads are labelled as samples, and nothing is changed.
Business outcome
---
Missing items and below cost web prices surface in one reconciliation report instead of spreadsheet matching.
scenario
-
To confirm a web order reached Dynamics GP, finance searches sales documents by customer and date and hopes the PO field holds the order number. Totals and statuses are compared by eye, and nobody is sure whether the order was invoiced or paid.
What popdock provides
--
Give a BigCommerce order number and a GP company. It reads the order status, payment status, total and lines, then searches PowerGP Online sales documents from a week before the order for one whose customer PO equals the order number. For a match it compares amount and status and checks receivables for an invoice and whether it is paid. If the order number is not recorded in GP it says so and offers close candidates labelled unconfirmed, never as a match. It stops if the order is not found, and nothing is changed.
Business outcome
---
Finance sees whether a web order was entered, invoiced and paid in GP, with any difference in total stated.
scenario
-
A billing question about one customer means opening Chargebee for subscriptions, invoices and payments, then the GP ledger for receipts and open items, and piecing the story together. A payment Chargebee shows as successful may never have been applied in GP, and nothing flags it.
What popdock provides
--
Name a customer by company or email. It finds the Chargebee customer, summarises active subscriptions with recurring revenue, invoices by status with amount due, and payments, then finds the PowerGP Online customer by name and reads their receivables and applied payments. You get a differences section listing successful Chargebee payments with no applied GP receipt within 7 days. If a match is ambiguous it stops, name matches are flagged unconfirmed, card and bank details are never shown, and nothing is changed in either system.
Business outcome
---
Support and finance answer a billing question from one combined view, with unapplied payments called out.
scenario
-
Payments taken in Chargebee have to be applied to the customer account in Dynamics GP, and checking each one means looking up the customer in both systems and scanning applied receipts. Slow checks mean unapplied payments are found late, when a customer disputes a balance.
What popdock provides
--
Say how many days to look back and, optionally, name one customer. It lists successful Chargebee payments in that window, finds each customer in PowerGP Online by company name and looks for an applied receipt with the same amount within 7 days or a matching reference number. You get a table marked Applied or Not found in PowerGP, with counts and the total of unapplied amounts. Customers not found in GP are listed as such, different currencies are shown as not comparable, card and bank details are never shown, and nothing is changed.
Business outcome
---
Unapplied Chargebee payments are listed with a total, so finance can chase them before the customer does.
scenario
-
Subscription products and prices live in Chargebee while items, costs and price lists live in Dynamics GP, and the two are updated by different people. Products exist on one side only, descriptions differ, and a price slips below cost without anyone comparing the two.
What popdock provides
--
Give a SKU or a piece of a product name and it reads matching Chargebee products and item prices, then looks up each in PowerGP Online by SKU or description for item number, cost and, optionally, price lists. You get three lists: matched, in Chargebee only and in PowerGP Online only, limited to 25 rows by default, with the Chargebee price beside GP cost and list price and any price below cost flagged. Products without a SKU are marked as name based matches, nothing is changed, and it stops if nothing matches.
Business outcome
---
One sided products and prices below cost are found by comparison instead of by accident.
scenario
-
Chargebee customers and PowerGP Online customers are created separately and drift apart. Nobody knows which billing accounts have no ledger customer, and finding out means exporting both lists and comparing names by eye, including the same company spelled two ways.
What popdock provides
--
Say how many customers to check and, optionally, a name filter. It reads Chargebee customers, then looks each up in PowerGP Online by company or full name, treating names as equal when they differ only by case, punctuation or a suffix such as Inc or LLC. You get three lists with counts: matched, in Chargebee only and ambiguous. Every match is flagged as name based and unconfirmed, it stops if Chargebee returns nothing, card and bank details are never shown, and nothing is changed.
Business outcome
---
Accounts that exist on only one side are listed with counts, ready for someone to review and fix.
scenario
-
Subscription invoices in Chargebee should tie back to the sales documents that billed the same work in Dynamics GP, and the only link is the purchase order number. Matching them by hand means reading PO numbers off two screens, and amount differences and orphans slip through.
What popdock provides
--
Say how many days to look back and, optionally, name a customer. It reads Chargebee invoices that carry a PO number, then looks in PowerGP Online sales documents for one whose customer PO matches, ignoring case and spaces. You get a table with invoice total, GP document amount and the difference, plus invoices with no PO number and PO numbers with no GP document. If several GP documents share a PO it shows them all and compares the sum, it stops if no invoice has a PO, card and bank details are never shown, and nothing is changed.
Business outcome
---
Invoice to sales document mismatches and orphans are listed in one pass, without matching PO numbers by hand.
scenario
-
To see whether a customer's Chargebee invoices agree with what Dynamics GP says they owe, someone pulls open receivables from one system and open invoices from the other and compares them by hand. Mismatched amounts and unmatched items are missed, and the gap between the two totals is never stated.
What popdock provides
--
Name a customer and, optionally, how many days of Chargebee invoices to read. It finds the customer in PowerGP Online and in Chargebee, reads open receivables and the Chargebee invoices, and pairs them by amount and date within 7 days or by invoice id in the document number. You get a table of pairings, unmatched items on each side, the total outstanding in each system and the gap. Ambiguous matches stop the run, differing currencies are shown separately, card and bank details are never shown, and nothing is changed.
Business outcome
---
Finance sees the gap between Chargebee and GP receivables with every unmatched item named, in one read-only reconciliation.
scenario
-
Before pay day, payroll administrators compare the pre-check summary with posted checks line by line to catch errors. Differences in gross or net wages, negative nets and sudden jumps over the prior run are easy to miss, and finding the pay code behind one means opening several more screens.
What popdock provides
--
Give the pay period end date, and optionally a company and employee class. It reads the pre-check summary, compares each employee's gross and net wages with the posted checks, and drills into employees with a difference, a net at or below zero or gross more than 25 percent above their prior run to show the pay codes behind it. You get totals, an employee count and an exceptions table. Payroll data is treated as confidential, so social security numbers and addresses are never shown, it stops if no run exists for that period, and nothing is changed in Dynamics GP.
Business outcome
---
Payroll errors are caught before pay day with the pay codes behind each exception, without exposing personal data.
scenario
-
To check one vendor in Dynamics GP, accounts payable staff open the vendor inquiry, then the payment history, then the 1099 screens, one after another. Year end is when it bites: a missing tax ID or a blank 1099 type is easy to miss across three screens and only shows up when the forms are due.
What popdock provides
--
Give a vendor ID or name and a year, and PowerGP Online finds the vendor in the Dynamics GP company you name. If more than one vendor matches, it lists them and stops rather than picking one. It then reads the open and closed payables documents, the payments applied to them and the 1099 rows for the year. You get one summary with balance, open documents, payments and 1099 total, and a missing tax ID is only reported when 1099 rows really came back with it blank. Nothing in Dynamics GP is changed.
Business outcome
---
You see a vendor's balance, payments and 1099 gaps in one read-only summary before year end, without guessing from empty results.
scenario
-
Planners scan stock reports for low items, then look up each one in the purchase order screens to see whether anything is already coming. Doing that by hand for dozens of items is slow, so an item runs out before anyone raises a reorder.
What popdock provides
--
Give a stock threshold, and optionally a location, and PowerGP Online finds the item sites at or below it in Dynamics GP. For the lowest items it reads the description, class and current cost, then checks open purchase orders for the next promised date. You get a ranked list marked reorder now, at risk or covered, with a suggested quantity only where the item has a fixed order quantity. Inactive item sites are skipped and counted, and no purchase order is created or changed.
Business outcome
---
Planners see which items need a reorder today, and which are already covered, before stock runs out.
scenario
-
Group finance leads who run several Dynamics GP companies log in to each one in turn, read off cash, payables and receivables, and paste the numbers into a spreadsheet. It is slow, and a company missed or a currency mixed in gives a comparison nobody can trust.
What popdock provides
--
Name the Dynamics GP companies to compare, and optionally one currency to total. PowerGP Online reads cash, payables owed and receivables owed from each company in turn and records which company, if any, could not be read. You get one table with a column per company and a note on the biggest vendor and customer balance. Only the companies you list are queried, currencies are never combined, and nothing in Dynamics GP is changed.
Business outcome
---
Group finance sees cash, payables and receivables for each named company side by side, with unreadable figures marked rather than hidden.
scenario
-
Budget owners export dimension balances and budgets from Dynamics GP into a spreadsheet, line them up by code and fiscal period, and work out where spending ran over. Then they go back into the system to find the postings behind the biggest overspends.
What popdock provides
--
Give a dimension group and a fiscal year, and PowerGP Online reads the actual balances by code and period, then the budgets for the same codes. For the five most overspent codes it lists the largest postings with date, document and amount. You get budget, actual, variance and variance percent per code, with overspends first, and a clear note where a code has no budget. If the group returns nothing it says so and stops without guessing another group. Nothing is changed.
Business outcome
---
Budget owners see which dimension codes are overspent and which postings drove it, without building a spreadsheet.
scenario
-
When a customer asks about their balance, an order or who their contact is, support and account managers open the customer card, then the addresses, then receivables, then sales documents. Each screen answers part of the question, and the full picture takes several minutes to assemble.
What popdock provides
--
Give a customer number or name, and PowerGP Online finds the customer in Dynamics GP. If several match, it lists them with balance due and stops. It then reads the addresses, the salesperson, the receivables split into open and paid with overdue items called out, and a 12 month summary of orders. You get one profile with up to three observations, such as a rising overdue balance. For the salesperson only name, ID and territory are shown, and nothing is changed.
Business outcome
---
Support and account managers answer a customer's question from one profile instead of four Dynamics GP screens.
scenario
-
Before payroll runs, HR admins scan the employee roster, then pay codes, then addresses and dependents to find anyone with a missing pay code or blank contact details. The checks sit on different screens, so gaps are found after a check is wrong rather than before.
What popdock provides
--
Name a company, and optionally a department, and PowerGP Online reads the employee roster, pay codes, addresses and dependents from Dynamics GP. You get headcount by status and class, then exceptions grouped by type: active employees with no pay code, pay codes that expired while the employee is still active, and missing address or phone. Employees are identified by ID and name only. Social security numbers, birthdays and home addresses are never printed, and nothing is changed.
Business outcome
---
HR finds pay setup gaps before payroll runs, without personal data appearing in the answer.
scenario
-
To explain a variance on a general ledger account, accountants run the account inquiry, then the budget view, then drill into journal entries one period at a time. Pulling those together takes a while, and large or undescribed entries are easy to overlook.
What popdock provides
--
Give an account number and a fiscal year, and PowerGP Online confirms the account in Dynamics GP, including its type and whether it is active. It reads period balances and budgets, then up to 500 transactions for the year. You get a period table of actual, budget, variance and variance percent, periods that vary by more than 20 percent, the 10 largest postings and any entries with no description. If the record limit is hit, it says the totals are partial. Nothing is changed.
Business outcome
---
Accountants see where an account moved against budget and which entries caused it, in one read-only review.
scenario
-
Collections staff export an aging report from Dynamics GP and then check each customer by hand for balance and recent payments. By the time the list is ready it is already stale, and customers with real exposure are easy to miss.
What popdock provides
--
Choose how many days past due to look at, and PowerGP Online reads the open receivables past that threshold from Dynamics GP. For the ten customers with the largest overdue totals it adds balance due, salesperson and contact, and checks whether recent payments were applied to older documents. You get a table grouped by aging bucket and a ranked chase list with one sentence of reasoning each. It stops if nothing is overdue, will not add amounts across currencies, and says when results are partial. Nothing is changed.
Business outcome
---
Collections starts the day with a current, ranked chase list instead of a stale export.
scenario
-
Treasury staff pull the payables due list in one place and the checkbook balances in another, then compare them in a spreadsheet to see if cash will cover the week. When the two views disagree or a checkbook is stale, the shortfall is found after payments are already due.
What popdock provides
--
Give a number of days ahead, and PowerGP Online reads the payables due in that window from Dynamics GP, the cash projection for the same dates and every checkbook balance. You get total due, total available, the shortfall or surplus, and the ten largest vendor payments. It flags checkbooks not reconciled in 35 days, documents already past due and mixed currencies instead of adding them. Payment suggestions are suggestions only: nothing is paid or scheduled.
Business outcome
---
Treasury sees whether cash covers what is due, and where it falls short, before the payment run.
scenario
-
Buyers check purchase order inquiry, then receipt entry, then the approval queue to see what is late, what is unapproved and what is still outstanding. With the three views kept apart, late and unapproved orders slip through until a vendor calls.
What popdock provides
--
Give a lookback period, and optionally a vendor, and PowerGP Online reads the purchase orders, receipts and approvals from Dynamics GP. Receipts are matched to orders by PO number, and a line only counts as received when a matching receipt exists. You get spend by vendor, orders past their promised date with nothing received, orders on hold or not approved, and the five biggest remaining commitments. Receipts that match no order are listed separately. Approvals and holds are never changed.
Business outcome
---
Buyers get a short list of orders that need action, with late and unapproved ones no longer slipping through.
scenario
-
Sales operations merge an order report, a hold report and a line report by hand to see what is booked, what is stuck and what is late. Orders sitting on a hold, or past their requested ship date, go unnoticed until the customer asks.
What popdock provides
--
Give a lookback period, and optionally a customer, and PowerGP Online reads sales documents, process holds and order lines from Dynamics GP. If a customer name matches several customers, it lists them and stops. You get totals by document type and status, documents stuck on a hold with their age in days, documents past the requested ship date that are not complete, and the top items by value. It never releases a hold or changes a document.
Business outcome
---
Sales operations see held and late orders in one summary, so none sit unnoticed until a customer complains.
scenario
-
Tracing an item, or running a recall, means checking site quantities, then lot quantities, then serial numbers, then the transaction history, one inquiry at a time. It is slow when speed matters, and it is easy to run a lot or serial check on an item that is not tracked that way.
What popdock provides
--
Give an item number, and PowerGP Online confirms the item in Dynamics GP, listing candidates and stopping if it cannot. It reads on-hand by site and bin, then lot and serial quantities only where the item is tracked that way, then the latest movements. You get one trace with lots flagged when they expire inside your window, serials on hand and the last ten movements. A mismatch between movements and on-hand is called out only when the numbers clearly disagree. Nothing is changed.
Business outcome
---
Warehouse staff trace where an item is and which lots are close to expiry from one read-only answer.
scenario
-
Spend with the same supplier can land in Ramp card transactions, Ramp reimbursements and Dynamics GP payables. Nobody sees the combined picture, so spend outside the approved payables process goes unnoticed and unsynced card spend sits waiting.
What popdock provides
--
Give a merchant name, a date range and a Dynamics GP company, and PowerGP Online reads that merchant's cleared Ramp card spend and reimbursements, then finds the vendor in Dynamics GP and reads its applied payments for the same dates. If several vendors match it lists them and stops, and if none match it says the merchant has no Dynamics GP vendor. You get side by side totals and a count of unsynced card spend. Refunds and declines are excluded and counted, totals are never added across systems, and nothing is written to either system.
Business outcome
---
Finance sees card spend, reimbursements and payables for one supplier side by side, and spots spend outside the payables process.
scenario
-
Vendors get paid by card in Ramp without ever being set up in the Dynamics GP vendor master. Finding them means exporting both vendor lists and eyeballing names, and similar names such as a shared first word make it easy to call two different suppliers the same one.
What popdock provides
--
Give a minimum spend and a GP company, and it reads your active Ramp vendors above that spend, highest first, up to 50. Each one is looked up in the GP vendor master by name, with one retry on the first word if the full name finds nothing. You get a table marking each vendor Matched, Not in GP or Ambiguous, with GP balance where found, and a list of the Not in GP vendors ordered by spend. Nothing is changed in Ramp or GP, and loose name matches are flagged instead of merged.
Business outcome
---
You see which card-paid vendors are missing from the GP vendor master, ranked by spend, without exporting or comparing lists by hand.
scenario
-
Buyers raise purchase orders in Ramp and in Dynamics GP separately. A quantity or unit price that drifts between the two copies is usually found only when the vendor invoice will not match, and receipts have to be checked in both systems too.
What popdock provides
--
Give a purchase order number and a GP company, and it finds the order in Ramp and in GP. If more than one Ramp order qualifies, it lists them and stops. It compares ordered total, line count, quantities and unit prices, then received quantities from Ramp item receipts against GP purchase receipts, listing each difference with both values. Lines with no shared id are paired by quantity and price, and any line it cannot pair is shown as unmatched. Nothing is changed in either system.
Business outcome
---
Drift between a Ramp order and its GP twin shows up before the invoice arrives, with every difference listed side by side.
scenario
-
When someone leaves, HR changes the employee status in Dynamics GP, but nobody cross-checks the Ramp user list. Leavers stay active as card users, and spotting them means comparing two lists person by person.
What popdock provides
--
Choose a GP company and a Ramp user status, and it reads the Ramp users, up to 200, then looks each one up in GP by employee id, falling back to name only when no id exists. You get lists of Ramp users with no GP employee, users active in Ramp whose GP employee is not active, name differences, and name-only matches marked low confidence, plus counts. Social security numbers, pay data and anything beyond the listed fields are never shown, and nothing is changed in either system.
Business outcome
---
Active Ramp users whose GP employee has left are found quickly, without exposing personal data or comparing lists by hand.
scenario
-
Accounts payable staff compare Ramp bills with Dynamics GP payables in two screens. Bills that never synced, or that carry a different amount or due date, go unnoticed until the vendor chases payment.
What popdock provides
--
Name a vendor, a GP company and how many days ahead to look, and it finds the vendor in GP, stopping to list the options if several match. It reads GP payables and Ramp bills due in the window and matches them by invoice number, ignoring spaces, case and leading zeros. You get four lists: matched and equal, matched with a different amount or due date, in Ramp only with sync status, and in GP only, with totals per side. It never guesses a match on amount alone, and nothing is changed.
Business outcome
---
Missing and mismatched bills are found before the vendor calls, with amounts and due dates shown side by side.
scenario
-
Accountants find out that a Ramp GL code does not exist or is inactive in Dynamics GP only when a sync fails. Nobody compares the two charts of accounts, and GP account numbers carry segment punctuation that makes manual comparison error prone.
What popdock provides
--
Give a GP company and optionally a code prefix, and it reads the active Ramp GL accounts, up to 200, then looks up each code in the GP chart of accounts, retrying by name if the number finds nothing. You get lists of Ramp codes not found in GP, accounts found but inactive or closed to account entry, and names that differ between systems, plus a count of matched accounts. Segment dashes and spaces are ignored when matching, and nothing is changed.
Business outcome
---
Broken or inactive GL mappings are found before a sync fails, from one short exception list instead of two charts side by side.
scenario
-
Before a payment run or a renewal call, someone opens Ramp, then Dynamics GP, then a spreadsheet to see what is owed to one vendor. The two views are never reconciled, and the same payment can be counted twice.
What popdock provides
--
Name a vendor and a GP company, and it reads the vendor in Ramp with year to date spend, unpaid bills and agreement end dates. It then reads the same vendor in GP with balance, open payables and purchase orders since a date you choose. If either system returns several vendors, it lists them and stops. You get one summary with identity, Ramp spend and open bills, agreements, GP balance and observations such as an agreement ending within 90 days. Ramp and GP amounts are shown side by side, never added, and nothing is changed.
Business outcome
---
You see one vendor's exposure in both systems side by side, with renewals and one-sided vendors flagged, before the call or payment run.
scenario
-
Prices and costs are checked item by item, one in the Dynamics GP price lists and one in the Shopify admin. Under-priced items and items sold below cost slip through, and a mismatch in unit of measure or currency makes the comparison misleading.
What popdock provides
--
Give an item number and optionally a price level, and it reads the GP current cost and price list, then the Shopify variant price, compare price and cost. You see GP price, GP cost, Shopify price, compare price, Shopify cost, the margin on each side and the gap, with a clear statement of whether prices match, Shopify is lower, or Shopify is below GP cost. Only the first price tier in the same unit of measure is compared, differing currencies are shown without conversion, and nothing is changed in either system.
Business outcome
---
Under-priced and below-cost items are spotted from one comparison with margins, instead of checking two systems item by item.
scenario
-
Stock counts are compared by hand between Dynamics GP and the Shopify admin. Oversells and stale quantities go unnoticed until a customer order cannot be filled, and the two systems rarely agree on how a SKU is written.
What popdock provides
--
Give a SKU, or leave it empty for a sample of up to 50 items, and it reads GP quantity on hand and on order across locations, then Shopify available stock for the same SKU. You get a table with GP on hand, GP on order, Shopify available, the difference and a verdict, sorted by the largest difference with oversell risk first. Matching is on exact SKU only, untracked Shopify items are reported as such, unmatched formats are listed instead of guessed, and nothing is changed.
Business outcome
---
Oversell risks and stale quantities surface first, ranked by size, without comparing counts by hand across two systems.
scenario
-
Someone scrolls through the Dynamics GP item list and the Shopify product list to find products that exist in only one system. SKUs that differ only in case or spacing are easy to miss, so gaps stay hidden until an order fails.
What popdock provides
--
Give an item class and a GP company, or leave them empty, and it reads up to 200 GP items and Shopify variants per side. Before declaring a GP item missing it checks the SKU directly in Shopify for up to 20 of them. You get three lists: GP items with no Shopify SKU, Shopify SKUs with no GP item, and a matched count, with look-alike SKUs flagged. Non-sales GP items are excluded and counted, a partial comparison is flagged when a side hits the limit, and nothing is changed.
Business outcome
---
Catalog gaps between GP and Shopify are listed in both directions, with partial results and near-miss SKUs called out.
scenario
-
Customer records are looked up separately in Dynamics GP and Shopify, and the two systems share no customer id. Duplicates and mismatched details persist because the only way to connect the records is by name and location.
What popdock provides
--
Give a customer number or name, and it finds the customer in GP, listing candidates and stopping if several match. It then looks for the same name in Shopify. You see GP balance due, Shopify total spent and order count, and city and state on each side, with whether they agree and a stated match confidence of exact name, partial name or none. A name alone is never treated as certain, differing locations are shown without deciding which is right, and nothing is changed.
Business outcome
---
You see whether a GP customer and a Shopify customer are the same person, with the confidence stated, before merging or acting on either record.
scenario
-
Web orders are checked against Dynamics GP sales documents by hand. Orders that never reached GP, or that were entered with a different amount, are usually found only at month end when the books will not agree.
What popdock provides
--
Choose how many days back to look and a GP company, and it reads recent Shopify orders and the GP sales documents for the same period. Orders are matched where the customer PO equals the Shopify order name or number, and amounts are treated as equal within one cent. You get counts of matched, missing and mismatched orders, with each exception shown with both amounts and the difference, paid orders first. Cancelled orders are reported separately, it stops if GP does not store order numbers, and nothing is changed.
Business outcome
---
Unposted and mis-valued web orders are found within days, not at month end, with each exception listed with both amounts.
scenario
-
Credit and collections staff check Dynamics GP aging, then open Shopify to look at orders and refunds, and piece the two together by hand. Total exposure to one customer is unclear until both views are combined.
What popdock provides
--
Give a GP customer number, and it reads the balance due and receivables transactions in GP, including overdue amounts by age. It then finds the matching Shopify customer by name and, only when exactly one matches, reads their orders, payment transactions and refunds. You get GP balance and overdue by age, unpaid or unfulfilled Shopify orders, recent refunds and total outstanding, with one line on whether exposure is rising. If the Shopify match is missing or ambiguous it reports GP only. It sends nothing, changes no holds or credit, and never mixes currencies.
Business outcome
---
You see one customer's total exposure across GP receivables and Shopify orders before deciding on credit or a collections call.
scenario
-
Stripe refunds and credit notes are easily left out of Dynamics GP, leaving receivables overstated. Checking means finding each refund in Stripe and hunting for a matching credit document in GP by amount and date.
What popdock provides
--
Name a customer and a start date, and it finds the customer in Stripe, listing the options and stopping if several match. It reads their refunds and credit notes since that date, then finds the customer in GP and reads credit memos and returns. Each Stripe item is paired with a GP credit of the same amount within 10 days, and a Stripe number found in the GP document number counts as a stronger match. You get matched pairs, Stripe credits with no GP document and GP credits with no Stripe source. Amount-only matches that are not unique are listed as candidates, and nothing is changed.
Business outcome
---
Refunds missing from GP are found before receivables are overstated, with uncertain matches listed instead of assumed.
scenario
-
Item catalogues live in Dynamics GP and Stripe and are maintained separately. To check one product you look up the GP item and its cost, hunt for the matching Stripe product by name, then open each Stripe price. A price that has slipped below cost, or a product that was switched off in Stripe while the item is still sold, goes unnoticed.
What popdock provides
--
Give an item number, or part of an item description, and it reads the item from PowerGP Online, then looks for the matching product in Stripe and reads its active prices. If more than five items match, it lists them and stops so you can narrow the search. You get a table per item with the GP cost, the Stripe name, whether it is active and each price, with Stripe prices below GP cost, inactive products and name differences flagged. Name matches are marked as likely, prices in a different currency are not flagged as a margin problem, and nothing is changed in either system.
Business outcome
---
Catalogue drift between GP and Stripe shows up as a short flagged list, with no records changed in either system.
scenario
-
Billing records drift between Stripe and Dynamics GP. To find Stripe customers who have no GP account you open each Stripe customer, search the GP customer list by name, and try again with a shorter name when nothing comes back. With dozens of customers this is slow, and the ones missing from GP are easy to overlook.
What popdock provides
--
Choose how many Stripe customers to check, and optionally only those created since a date. It reads the Stripe customers, then looks each name up in PowerGP Online, trying the first word when the full name finds nothing. You get three lists: customers matched to one GP customer, customers matched to several with the candidates shown, and unmatched customers with their Stripe ID, name, email and delinquent flag. Matches are labelled likely, never certain, a customer without a name is reported as unmatched, and nothing is changed in either system.
Business outcome
---
You see which Stripe customers have no GP account in one pass, with likely matches clearly separated from certain ones.
scenario
-
Reconciling Stripe payouts to the bank means listing payouts by arrival date, then scrolling the GP checkbook for deposits that look like them. A payout is paid net of fees, so the amounts rarely match exactly and genuine deposits get flagged as mismatches while real gaps are missed.
What popdock provides
--
Give a date range and a GP checkbook. It first confirms the checkbook exists in PowerGP Online and shows its balance and last reconciled date, then reads the Stripe payouts that arrived in the range and the deposits in the checkbook. Payouts are paired with deposits of the same amount within five days, and near matches within five percent, which usually means fees, are listed separately. You get matched items, payouts with no deposit, deposits with no payout and the net unrecorded amount. Failed payouts are listed but not matched, amounts are not compared across currencies, and nothing is changed.
Business outcome
---
Stripe payouts and GP deposits are reconciled with fee differences separated, and unrecorded payouts are named.
scenario
-
When a customer pays through Stripe, the amount owed in Dynamics GP and the invoices in Stripe should agree. Checking means finding the customer in both systems, totalling open receivables in GP, then totalling Stripe invoices and charges, usually by hand. Differences are missed or blamed on the wrong cause.
What popdock provides
--
Give a customer name and, if you like, a GP company and how many days to look back. It finds the customer in PowerGP Online and stops with a list if several match, then totals their open receivables. It finds the same customer in Stripe by name, again stopping if several match, and totals invoices and charges. You get a table of GP balance, GP open receivables, Stripe amount remaining and amount paid, the difference, and likely causes such as payments not yet applied or refunds. Amounts in different currencies are shown separately, and nothing is changed.
Business outcome
---
You see the gap between GP and Stripe for one customer, with the likely cause, before it turns into a dispute.
scenario
-
Web orders are meant to flow into the ERP, but confirming that one did means searching Dynamics GP sales documents by amount and date. You read the WooCommerce order, guess a date window, scan documents for a matching total, and check the customer name by eye. Several close candidates make it easy to pick the wrong one.
What popdock provides
--
Give a WooCommerce order number and a PowerGP company. It reads the order and its lines, then searches PowerGP Online sales documents in a window around the order date for a total within one unit, checking the customer name and PO number and optionally comparing lines by SKU. You get the order summary, the matching sales document or a clear statement that none was found, and the amount difference. When several documents match it lists them all instead of choosing, it notes that a missing document may be expected for unpaid or cancelled orders, and it never changes WooCommerce.
Business outcome
---
You know whether a web order reached Dynamics GP, with the amount difference, and ambiguous matches are never guessed.
scenario
-
Selling prices are set in WooCommerce while costs live in Dynamics GP. To see margins you export products, export item costs, line them up by SKU and work out the percentages. Until someone does that, thin margins and products selling below cost stay live on the store.
What popdock provides
--
Name a product or leave it open for the first 50, optionally add a GP company and a minimum margin, which defaults to 20 percent. It reads the WooCommerce prices, looks up each SKU as an item in PowerGP Online and reads its current cost. You get a table sorted from lowest margin up, with rows below your threshold and rows selling below cost marked. Products with no price are skipped and listed, products with no GP match are listed as having no cost, margins are called indicative when currencies may differ, and nothing is changed.
Business outcome
---
Low and negative margins on the web store are found from one request, with the unmatched products listed rather than guessed.
scenario
-
Products get listed on the web store before anyone sets them up as items in Dynamics GP. Finding the gaps means exporting the WooCommerce catalogue and checking each SKU against the item master. Nobody notices until an order arrives that cannot be fulfilled or costed.
What popdock provides
--
Choose a product status, which defaults to published, and a PowerGP company. It reads up to 100 WooCommerce products and looks each SKU up as an item in PowerGP Online. You get two lists: products with no PowerGP item, showing product ID, name, SKU, price and stock, and products with no SKU, which cannot be matched. It ends with counts of matched, missing and unmatchable products. If a GP item has a very different description it is flagged as a possible SKU collision instead of a match, and nothing is changed.
Business outcome
---
Web products missing from the ERP are listed before an order exposes them, with SKU problems called out.
scenario
-
A web customer contacts support and you need to know what they owe. WooCommerce knows their email and orders, but Dynamics GP has no email filter, so you hunt through customers by name and often land on the wrong account. Then you open receivables to see what is outstanding.
What popdock provides
--
Give the customer's email address and, if you like, a GP company. It finds the WooCommerce customer and their ten most recent orders, and stops with a list if more than one record has that email. It then searches PowerGP Online by company name or last name and lists candidates with number, name, state and balance. A match is accepted only when the name clearly agrees, otherwise you are asked to pick. You get the web profile and orders, the GP match and confidence, the balance due and the open items. Nothing is changed.
Business outcome
---
Support finds the right GP account and balance for a web customer, and unclear matches are put to a person instead of guessed.
scenario
-
Stock on the web store and stock in Dynamics GP are meant to agree, but they are compared by hand, SKU by SKU, in two different screens. GP holds quantities by location, so you add them up first. Oversells and phantom stock go unnoticed until a customer complains.
What popdock provides
--
Name an item or SKU, or leave it open for up to 50 products, and optionally a PowerGP company. It reads the WooCommerce stock, skipping and listing products with no SKU, then reads the item quantities in PowerGP Online for each SKU and adds up the quantity on hand across locations. SKUs are matched ignoring case and spaces. You get a table of web stock, GP on hand, difference and GP on order, grouped into matches, mismatches, products missing from GP and products that do not track stock. Unmatched SKUs are listed, not guessed, and nothing is changed.
Business outcome
---
Stock differences between the web store and Dynamics GP are listed by SKU, so oversells are caught before customers hit them.
scenario
-
Buyers see best sellers in the web store, but stock and purchase orders sit in Dynamics GP. To decide what to reorder you pull the top sellers, look up each SKU, add up stock by location and check for open purchase orders. By then demand has often moved ahead of the restock decision.
What popdock provides
--
Optionally set a stock threshold, which defaults to 10, and a PowerGP company. It reads the ten WooCommerce top sellers with their SKU and web stock, then reads PowerGP Online stock on hand and on order for each SKU. For items below the threshold it also reads the open purchase orders with vendor, quantity and promised date. You get a table with units sold, web stock, GP on hand, on order, next promised date and a status of Covered, Watch or Restock. Products with no SKU or no GP item are listed as unmatched, and nothing is changed.
Business outcome
---
Buyers see which web best sellers need restocking and what is already on order, in one table.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.