.webp){kind=logo}
ERP
Microsoft Dynamics 365 Business Central
Connect your AI to Microsoft Dynamics 365 Business Central
Business Central connects purchasing, warehouse, finance, and sales into a single platform, but the answers each team needs are locked behind navigation expertise and system access most roles won't build. AI bridges that gap in plain language, but only within the permissions, field logic, and company structure that each implementation enforces.
Why it matters
Capabilities that matter most for Microsoft Dynamics 365 Business Central
01
Build lists with the Query Builder
Pick Business Central tables, join them, restrict them and choose the fields, all without AL code. Build in a sandbox, review the differences, then publish the list straight to production as a validated extension.
02
Popdock inside Business Central pages
Publish Popdock widgets onto the Business Central pages your team already uses, so related data from other systems shows up next to the customer, vendor or item they are looking at.
03
Compare every company side by side
Comparison and matrix lists line up the same figures across every Business Central company, by calendar month or fiscal period, so consolidation questions stop needing a spreadsheet.
03
Governed AI over every company
MCP tools answer from Business Central through the company structure and per-user, per-team security you set, with 48 ready-made API endpoints and lookups in the app store.
Use cases
Example AI Use Cases for Microsoft Dynamics 365 Business Central
scenario
-
The money for a job lives in Dynamics 365 Business Central and the delivery lives in Asana. Seeing both means pulling budget against usage from one system and open, overdue and unassigned tasks from the other, then working out whether they tell the same story.
What popdock provides
--
Give a job number and it reads the job and its tasks from Business Central, works out cost used against budget, then finds the matching Asana project and its open, overdue and unassigned tasks and latest status. You get one brief with money and delivery side by side and a one-line verdict. It flags clearly when the two disagree, such as cost usage over 90 percent while Asana says on track. Nothing is changed in either system.
Business outcome
---
Project and finance teams share one view of each job, so budget overruns and delivery slips are spotted together.
scenario
-
A salesperson's opportunities and customer balances sit in Dynamics 365 Business Central while their follow-up work sits in Asana. A manager trying to judge their capacity, or spot deals nobody is chasing, has to look in both places and match them up.
What popdock provides
--
Give a salesperson code and it reads their open opportunities and customers with a balance due from Business Central, then finds them in Asana by email and reads their open tasks. You see the pipeline, balances and workload together, with past-due closing dates flagged. It checks whether each opportunity closing in the next 30 days and each of the largest balances has an Asana task, and lists the ones with nothing tracked. It only reads both systems.
Business outcome
---
Deals and balances nobody is following up are found before they slip, with each salesperson's workload in view.
scenario
-
People track time in Asana while the hours that get billed come from Dynamics 365 Business Central timesheets. When the two disagree, hours go unbilled or get billed twice, and checking them means matching people and totals across two systems.
What popdock provides
--
Give a job number and a date range, and it reads the job's timesheet lines in Business Central and the time tracked on the matching Asana project, then compares them person by person. Differences over 10 percent or 2 hours are flagged, people found on only one side are listed, and it notes how many timesheet lines are not yet posted or approved. People are matched by name and never guessed. Nothing is changed in either system.
Business outcome
---
Billable hours are reconciled before invoicing, so time is neither lost nor billed twice.
scenario
-
Overdue invoices sit in Dynamics 365 Business Central, but the people who chase them plan their day in Asana. Turning the overdue list into assigned follow-up tasks by hand is slow, and it is easy to create a second task for an invoice someone is already chasing.
What popdock provides
--
Set how overdue and how large an invoice must be, and it finds the matching posted sales invoices in Business Central and works out each customer's salesperson in Asana by email. Invoices that already have an open task are skipped. You see the full list of tasks it would create, with assignee and amount, and nothing is created until you confirm. Each task carries the customer, invoice, due date and amount, and Business Central is never changed.
Business outcome
---
Every overdue invoice has an owner and a task, with no duplicate chasers and no invoice forgotten.
scenario
-
Opportunities in Dynamics 365 Business Central have closing dates, but salespeople work from their Asana task lists. Deals closing soon, or already past their date, slip when nobody has a task to follow them up.
What popdock provides
--
It finds open Business Central opportunities closing in the next 14 days, or the window you choose, including any already past their date, and matches each salesperson to their Asana user by email. Opportunities that already have an open task are skipped. You see each task it would create, with value, company and closing date, and nothing is created until you confirm. Each task is assigned to the salesperson and due on the closing date. Business Central is never changed.
Business outcome
---
Every deal closing soon has a follow-up on the right person's list, so fewer opportunities slip past their date.
scenario
-
Before a customer call you want the full picture: what they owe and how late it is from Dynamics 365 Business Central, and what work is in flight for them in Asana. Gathering that means visiting several screens in two systems.
What popdock provides
--
Give a customer number and it reads the customer's balance, credit limit, overdue invoices, open jobs and recent comments from Business Central, then finds the Asana tasks and projects that mention them. The brief puts money and work side by side and highlights overdue invoices with no follow-up task and open jobs with no Asana project. Where a customer name is too short or common to search reliably, it says so and narrows the match. It only reads both systems.
Business outcome
---
Account conversations start fully informed, and overdue invoices nobody is chasing are surfaced first.
scenario
-
The project team in Asana rarely sees the job's budget against usage, which sits in Dynamics 365 Business Central. Keeping them informed means someone copying figures across and judging whether the job is still on track.
What popdock provides
--
Give a job number and it totals the job's cost and price budget against usage in Business Central and reads the matching Asana project's open and overdue tasks and last status. It drafts a status update using clear rules, for example at risk once cost usage passes 80 percent, with the figures and a one-line recommendation. You confirm or edit the draft before it is posted to the Asana project. Business Central is never changed.
Business outcome
---
Delivery teams see the job's financial position where they work, so overspend is addressed before the job closes.
scenario
-
Jobs in Dynamics 365 Business Central and projects in Asana should line up, but jobs are opened without a project, projects run without a job, and completion and dates disagree. Finding those gaps across two systems is a manual matching exercise.
What popdock provides
--
It reads Business Central jobs with the status you choose, Open by default, and your active Asana projects, and matches them by job number in the project name, or by description. It reports matched pairs that disagree on completion or by more than seven days on dates, jobs with no project, projects with no job, and ambiguous matches it will not guess at. It never matches on customer name alone, and it changes nothing in either system.
Business outcome
---
Every job has a delivery plan and every project has a job, so work is tracked and billed consistently.
scenario
-
Every Bloomerang fund carries a general ledger class that should point at a real Dynamics 365 Business Central account, but accounts get blocked, renumbered or turned into headings. You only find out when gifts fail to post, and checking each fund against the chart of accounts by hand is slow.
What popdock provides
--
Optionally name a Business Central company, and it reads every active Bloomerang fund and looks up its GL class as a G/L account number, checking dimension values when no account matches. Each fund is rated OK, blocked, no direct posting, dimension not account, missing or not found, with the matched account's name and type. Numbers are compared exactly, so a near miss such as 4000 against 40000 is reported as not found with a note rather than guessed. It only reads, and if Business Central fails for the company it stops instead of marking every fund missing.
Business outcome
---
Broken fund mappings are fixed before gift posting fails, not discovered after month end.
scenario
-
When a sponsor needs an invoice, someone has to set them up as a Dynamics 365 Business Central customer using details that already live in Bloomerang. Rekeying the name, email, phone and address invites typos, and it is easy to create a second customer for an organization that already exists.
What popdock provides
--
Name the Bloomerang organization, and optionally a Business Central company, and it finds the organization with its primary address and phone. It searches Business Central for an existing customer by email and by name, and never creates one when a likely match exists. You see the customer it would create and can supply a customer number, and nothing is written until you confirm. Once the customer is created, a note with the new customer number is added to the Bloomerang record and the customer is read back; if creation fails, no note is added.
Business outcome
---
Sponsors become Business Central customers once, with accurate details and a link back on their donor record.
scenario
-
Gifts recorded in Bloomerang need to reach Dynamics 365 Business Central, but some sit in an unposted journal and others never arrive. Finding which ones means checking each gift against both the ledger and the journals, which nobody has time for at month end.
What popdock provides
--
Give a date range, and optionally a company, and it reads the Bloomerang gifts and looks for each one in Business Central by its BLM document number, first in posted ledger entries and then in unposted journal lines. Gifts are counted as posted, in journal with the batch name, or missing, and the missing ones are listed with donor, amount and method, with refunded gifts flagged. It only reads. If nothing in the period is found at all, it warns that gifts may have been posted as daily totals and suggests a revenue reconciliation instead.
Business outcome
---
You know exactly which gifts still need posting before you close the period.
scenario
-
Sponsors often pay invoices in Dynamics 365 Business Central and also appear as donors in Bloomerang, and the two records rarely line up. Matching payments to gifts by amount and date by hand is fiddly, and a payment that was never recorded as a gift easily goes unnoticed.
What popdock provides
--
Name the organization and a look-back period, and optionally a company, and it finds the matching constituent and Business Central customer, stopping if either side is missing or ambiguous. It reads the customer's payments and the organization's gifts, then pairs them when amounts match and dates fall within seven days, preferring a check number match and using each record once. You get paired items, payments with no gift and gifts with no payment, with totals and a likely reading of each. It only reads, and differences of cents or currency are left unpaired and mentioned.
Business outcome
---
Sponsor payments and gifts are reconciled in minutes, and unrecorded gifts surface before acknowledgements go out.
scenario
-
Getting a period of Bloomerang gifts into Dynamics 365 Business Central means rekeying each fund designation as a journal line against the right G/L account. It is slow, and it is easy to post a gift twice or to an account that is blocked or closed to direct posting.
What popdock provides
--
Give a date range and the deposit account, and optionally a company, and it reads the gifts and their fund designations, leaving out refunds. Any gift already in Business Central as a ledger entry or journal line is skipped, and every account is checked, so gifts needing a missing, blocked or non-posting account are left out and listed. You see each planned line and the total before anything is written. After you confirm it creates one new journal and its lines, then reads them back and compares the count and total with the plan. The journal stays unposted for your review.
Business outcome
---
Gifts reach Business Central as a ready-to-review journal, with no double posting and no bad accounts.
scenario
-
At period end, the gift total for each fund in Bloomerang should agree with what Dynamics 365 Business Central shows on that fund's G/L account, but it rarely does at first. Tracking down the gap means listing gifts and ledger entries side by side for every fund.
What popdock provides
--
Give a date range, and optionally a company, and it totals Bloomerang gifts by fund from the designations, keeping refunds separate. Each fund is mapped to its G/L account and compared with the net credits Business Central shows for the period, with a status of matched, Bloomerang higher, Business Central higher or unmapped. For every gap it lists the entries and gifts behind it, pairing gift entries by their BLM document number. It only reads, and extra entries without that number are called probable non-gift income rather than errors.
Business outcome
---
Fund revenue ties out between your donor system and the ledger, with every variance explained.
scenario
-
An organization can be a generous sponsor in Bloomerang and at the same time carry overdue invoices in Dynamics 365 Business Central. Seeing both means looking the organization up in each system, and matching by name alone can merge two different companies.
What popdock provides
--
Name the organization, a look-back period and optionally a company, and it finds the Bloomerang organization, then the Business Central customer by email first and by name second, asking if several match. You get gift count, total, largest and latest gift beside the customer's balance, credit limit, blocked status, open invoices and overdue total, with a line on what stands out. It says whether the match was by email or by name, and never merges organizations that only share a word. It only reads, and if no customer exists it reports the giving alone.
Business outcome
---
You see a sponsor's giving and what they owe in one view before your next conversation with them.
scenario
-
Your customers live in Dynamics 365 Business Central, but your newsletter audience lives in Constant Contact, and the two drift apart as new accounts open. Finding who is missing means exporting customers, checking each email in Constant Contact and adding the gaps one by one, often with no record of consent.
What popdock provides
--
Name a Constant Contact list, and optionally a salesperson or state, and it reads the active Dynamics 365 Business Central customers with an email and checks each one in Constant Contact. Customers already in Constant Contact are listed separately, since they must be added to the list there by hand. You see every customer to be added with their number, name, email and phone, and nothing is created until you confirm. Permission to send is left unset unless you say they opted in, it stops on the first error, and Business Central is never changed.
Business outcome
---
Your marketing audience keeps pace with your customer base, without duplicates or consent you never recorded.
scenario
-
Collections often starts with an email reminder, but some overdue customers in Dynamics 365 Business Central have an address that bounces, an unsubscribe on file or no email at all. You find out only after the reminder fails, and the balance sits for another week.
What popdock provides
--
Optionally set a minimum balance due, and it lists the active Dynamics 365 Business Central customers who owe money, highest balance first. Each email is checked in Constant Contact for a missing contact, a bounce or an unsubscribe, with the bounce type or reason and date. You get a table of the customers with a problem, with their phone number and salesperson, plus how many have a usable email. It notes that a marketing unsubscribe does not block a collections email, suggests phoning hard bounces, and changes nothing in either system.
Business outcome
---
Collections phones the customers email cannot reach, so overdue balances get chased through a channel that works.
scenario
-
Before you call a customer, the full picture sits in two places: their subscription and email history in Constant Contact, and their balance, open orders and invoices in Dynamics 365 Business Central. Switching between them, it is easy to miss that a customer who owes money has unsubscribed or that the company name does not match.
What popdock provides
--
Give an email address, and optionally a look-back period, 90 days by default, and it reads the person's Constant Contact permission, lists, tags, recent activity, bounces and unsubscribes. It then finds the matching Dynamics 365 Business Central customer, or a contact if there is no customer, with balances, open sales documents and recent posted invoices. Conflicts are flagged, such as a bounce on an active customer or company names that differ, and several matching customers are each reported rather than one picked. Neither system is changed.
Business outcome
---
You see one customer's marketing and account standing side by side, and spot conflicts before your next conversation.
scenario
-
People who click a Constant Contact campaign are showing interest, but if they are not already in Dynamics 365 Business Central, sales never sees them. Adding them by hand means checking each email against customers and contacts, then typing in names, companies and job titles.
What popdock provides
--
Name the Constant Contact campaign, and it gathers everyone who clicked a link along with their contact details, then checks each email against both customers and contacts in Dynamics 365 Business Central. Only people found in neither are proposed, matched on email and never on name. Business Central needs a job title, so anyone without one is marked and you choose to skip them or supply a value. Contacts are created only after you confirm, and you get a report of created, skipped and failed, with each new contact number.
Business outcome
---
Interested prospects from your campaigns reach Business Central as contacts, without duplicating anyone already on file.
scenario
-
After a campaign, sales wants to know which clickers are worth a call, but the click report in Constant Contact says nothing about who is already a customer or in an open deal in Dynamics 365 Business Central. Checking each email against customers, contacts and opportunities takes most of an afternoon.
What popdock provides
--
Name the Constant Contact campaign and it groups everyone who clicked by email, with their click count and the links they chose. Each person is placed in Dynamics 365 Business Central as a customer, a contact with an open opportunity, a contact without one, or unknown, and an opportunity counts only when it belongs to that contact. Near-matching company names are noted rather than silently accepted. You get one table ordered by clicks with status, opportunity value and salesperson, and nothing is changed.
Business outcome
---
Sales gets a ranked follow-up list of campaign clickers, with existing customers and live deals already separated out.
scenario
-
Showing that an email campaign led to sales means matching everyone who opened or clicked to customer records in Dynamics 365 Business Central, then adding up the invoices posted in the weeks after the send. By hand that is a spreadsheet of lookups few teams ever finish.
What popdock provides
--
Name the Constant Contact campaign, and optionally an attribution window, 30 days by default, and it collects everyone who opened or clicked, noting which did which. Each email is matched to Dynamics 365 Business Central customers, never by name, and the posted sales invoices in the window after the send are totalled, split by currency where needed. You get the engaged count, matched customers, buyers and invoiced amount, with a table per buying customer. It states plainly that this is correlation within a time window, not proof the campaign caused the sale, and it only reads.
Business outcome
---
You can put a revenue figure next to a campaign, with an honest caveat about what that number does and does not prove.
scenario
-
Active customers in Dynamics 365 Business Central should be reachable in Constant Contact, but some never made it across, some unsubscribed, and some have no email on file at all. Finding which is which means checking customers one at a time against your contacts.
What popdock provides
--
Optionally name a salesperson and how many customers to check, 50 by default, and it reads the active Dynamics 365 Business Central customers and looks up each email in Constant Contact. Email is the only key, never a name, and duplicate contacts are noted. You get a count line and three tables: customers missing from Constant Contact, customers there who cannot be emailed because of their permission status, and customers with no email in Business Central. Nothing is changed in either system.
Business outcome
---
You know exactly which customers your campaigns are missing and why, ready to close each gap in the right place.
scenario
-
Job titles, company names and phone numbers change, and the update usually lands in Dynamics 365 Business Central while Constant Contact keeps the old values. Comparing a whole list by hand to bring them in line is slow, and it is easy to wipe a good value with a blank one.
What popdock provides
--
Name a Constant Contact list and it reads each member, finds the Dynamics 365 Business Central contact with the same email, and compares company name, job title and phone, ignoring case, spacing and phone punctuation. A blank value in Business Central never counts as a difference, and members with several matches are left alone. You see a table of differences and choose all, some or none, then only the changed fields are updated in Constant Contact. Email addresses and permission are never touched, and Business Central is not changed.
Business outcome
---
Your email audience carries current titles, companies and phone numbers from Business Central, without good data being overwritten.
scenario
-
DonorPerfect assigns a GL code to every gift, and each one needs a matching Dynamics 365 Business Central account that can take a posting. When an account has been blocked, renamed or turned into a heading, gift entries start failing and nobody knows which codes are affected.
What popdock provides
--
Optionally name the Business Central company and whether to include inactive codes, and it collects every DonorPerfect GL code and every campaign mapped to an account, then looks up each account in Dynamics 365 Business Central. Each code is classed as missing, blocked, not a posting account, closed to direct posting, a balance sheet account worth reviewing, or OK. Formatting differences are retried once and reported. You get a table and one line per problem group saying what to fix and where. Nothing is changed in either system.
Business outcome
---
Broken GL code mappings are found and explained before they cause rejected journal lines at month end.
scenario
-
Organisations that both donate to you and invoice you deserve a closer look, but DonorPerfect and Dynamics 365 Business Central never compare notes. Finding the overlap means matching vendor names and emails against donor records and then adding up gifts and purchases for each.
What popdock provides
--
Give a start date, the first of the year by default, and it reads your active Dynamics 365 Business Central vendors and searches DonorPerfect for each by email, then by name with legal suffixes removed. A name-only match counts as confirmed only when city or state agree. For each match it totals gifts, including in-kind gifts, and posted purchase invoices. Patterns such as rising gifts alongside rising purchases are flagged for a human to review, clearly not as findings of wrongdoing, and nothing is changed.
Business outcome
---
Potential conflicts of interest between donors and vendors surface for review, backed by real gift and purchase totals.
scenario
-
Some of your donors are also customers you invoice, but development staff work in DonorPerfect and finance works in Dynamics 365 Business Central. Without a combined view, a team can make a major ask of an organisation that has unpaid invoices outstanding.
What popdock provides
--
Set a minimum lifetime giving level, 1000 by default, and optionally a name, and it reads matching DonorPerfect organisation donors and looks for each in Dynamics 365 Business Central by email, then by name. A name-only match is labelled as such unless city or state agree, and multiple candidates are all listed rather than one picked. Each match shows giving next to sales, balance due and open invoices, and donors with money owed who gave this year are called out. It is read-only.
Business outcome
---
Development and finance see the same relationship picture, so asks and invoices are coordinated rather than colliding.
scenario
-
Getting gifts from DonorPerfect into Dynamics 365 Business Central usually means retyping them as journal lines, checking each GL code is a valid account, and hoping none were entered last week too. A duplicate or a line against a blocked account means rework for the accountant.
What popdock provides
--
Give a date range and a balancing account, and it reads the DonorPerfect cash gifts, leaving out pledges, soft credits and gifts with no GL code. Each gift is checked against Dynamics 365 Business Central journal lines and ledger entries by its reference number, and each GL code against the chart for a usable posting account. You see the full plan with every skipped gift and its reason, and lines are created only after you confirm. The journal is never posted, and DonorPerfect is never changed.
Business outcome
---
Gift revenue arrives in Business Central as a review-ready journal, with no duplicates and no lines against unusable accounts.
scenario
-
Proving that gift revenue in DonorPerfect matches the Dynamics 365 Business Central ledger means totalling gifts by GL code, pulling posted entries for each account and chasing every difference item by item. Pledges and soft credits make the totals look wrong even when they are not.
What popdock provides
--
Give a date range and optionally one GL code, and it totals DonorPerfect cash gifts per code, excluding pledges and soft credits, then sums net credits on each matching Dynamics 365 Business Central account, ignoring reversed entries. Each code shows both totals and the difference, and codes with no account or no postings are named. For the three largest differences it lists the gifts and entries behind them and points out likely matches. It asks for the period rather than guessing and changes nothing.
Business outcome
---
Month-end gift revenue reconciliation is done in one pass, with the items behind every difference already identified.
scenario
-
A sponsor organisation can appear as a donor in DonorPerfect and a customer in Dynamics 365 Business Central at the same time. Before a renewal ask or a collections call, someone has to gather gifts, pledges, invoices and notes from both systems to avoid an embarrassing overlap.
What popdock provides
--
Name the organisation and a lookback period, 365 days by default, and it finds the DonorPerfect donor, asking you to pick if several match, and reads its gifts, open pledges and recent contacts. The same organisation is found in Dynamics 365 Business Central and its invoices, open balances, quotes, orders and customer comments are read. The combined view adds watch points such as overdue invoices next to an open pledge or a payment that may be recorded twice. It is read-only.
Business outcome
---
You see the whole sponsor relationship, giving and billing together, before the next ask or invoice goes out.
scenario
-
When a donor needs to be invoiced, someone has to retype their name and address from DonorPerfect into Dynamics 365 Business Central and check they are not already a customer. Without a note back on the donor, the next person has no idea a customer record exists.
What popdock provides
--
Give a DonorPerfect donor id and it reads the donor and their main or billing address, then searches Dynamics 365 Business Central by email and by name. If a customer already exists, it shows it and stops. Otherwise you see the exact customer to be created, with the country converted to a two-letter code, and it is created only after you confirm, then read back. The new customer number is then noted on the donor in DonorPerfect, and if that note fails you are given the number to add by hand.
Business outcome
---
Donors become invoiceable customers once, with no duplicates, and both systems record the link between them.
scenario
-
Adding an item in Dynamics 365 Business Central means searching by number, barcode and description first, because a duplicate item splits stock and sales history across two records. Then each variant has to be added separately, and a price set below cost slips through unnoticed.
What popdock provides
--
Describe the item, its details and any variants, and it searches Dynamics 365 Business Central for existing items by description, item number and GTIN, plus catalog entries, and shows any matches before going on. It collects the type, unit, price, cost and category, asks for the type rather than assuming one, and warns if the price is below cost. You see the item and every variant exactly as they will be created, nothing is written until you confirm, and the result is read back. At most one item is created.
Business outcome
---
New items and their variants are added once, with sensible pricing, and no duplicate records splitting your stock.
scenario
-
Changing a date, reference or line on an open purchase order, invoice or credit memo in Dynamics 365 Business Central means finding the document, checking it is still open and editing the right line. Lowering a quantity below what has already been received, or editing a posted invoice, causes real problems.
What popdock provides
--
Name the document and describe the changes, and it finds the open purchase order, invoice or credit memo in Dynamics 365 Business Central, stopping and explaining if the document is posted or released. It reads the lines and any comments that may explain the current values, and never lowers an order quantity below what was received. You see a before-and-after table, only the changed fields are written after you confirm, and the document is read back. If it is unclear which line you mean, it asks, and dropped lines are set to zero quantity with a note.
Business outcome
---
Purchase document corrections are made accurately, to the right line, without touching posted or released documents.
scenario
-
Customers change their minds about dates, quantities and references, and each change means editing an open sales quote, order, invoice or credit memo in Dynamics 365 Business Central. Editing a released document, cutting a quantity below what has shipped, or adding a blocked item leads to errors downstream.
What popdock provides
--
Name the sales document and the changes, and it finds it in Dynamics 365 Business Central, stopping if it is posted, when a credit memo is needed instead, or not open. It reads the lines, refuses blocked items on new lines and never lowers an order quantity below what has shipped. You review a before-and-after table for every field and line, only the fields that change are written after you confirm, and the new values are read back. If it is unclear which line you mean, it lists them and asks.
Business outcome
---
Sales document changes go through cleanly, keeping shipped quantities and posted invoices safe from accidental edits.
scenario
-
When a G/L account balance moves unexpectedly, finding out why means scrolling through hundreds of ledger entries in Dynamics 365 Business Central, grouping them by source and spotting the large or unusual ones. Reversals, weekend postings and blank descriptions are easy to miss.
What popdock provides
--
Name the account and a period, the current month to date by default, and it finds the account in Dynamics 365 Business Central, asking you to choose a posting account if you named a heading or total. It reads the ledger entries and totals debits, credits and net movement by document type and source, lists the ten largest entries, and points out reversals, weekend postings, blank descriptions and a single user posting most entries. A short narrative explains the movement. It describes rather than accuses and changes nothing.
Business outcome
---
You can explain an account's movement in minutes, with the entries that matter already picked out.
scenario
-
Customer records in Dynamics 365 Business Central drift over time: credit limits get breached, blocked customers still owe money, and terms, emails or salespeople go missing. Nobody notices until a collections call, a statement run or a credit decision goes wrong.
What popdock provides
--
Optionally name a salesperson, and it reads your Dynamics 365 Business Central customers and checks each one against clear rules: over credit limit, a balance with no limit set, blocked with money owed, missing payment terms, contact details, salesperson or country, and possible duplicates by name or email. For the ten most over their limit it shows overdue invoices. You get a count and table per rule and the ten most urgent fixes. It says when results hit the read limit and changes nothing.
Business outcome
---
Credit risks and gaps in customer data are found in one sweep, with the most urgent fixes listed first.
scenario
-
Item data problems in Dynamics 365 Business Central cost money quietly: an item priced below cost, an item with no price, negative inventory, or a blocked item that customers are still ordering. Finding them means filtering and sorting the item list again and again.
What popdock provides
--
Optionally name an item category, and it reads your Dynamics 365 Business Central items and tests each against set rules: priced below cost, no price, no cost while in stock, negative inventory, no vendor or reorder point on stocked items with sales, blocked items with demand, and missing barcodes where most items have one. For blocked items with demand it lists the affected sales orders. You get a count and table per rule, and nothing is changed.
Business outcome
---
Pricing and item data problems surface before they erode margin or hold up orders for blocked items.
scenario
-
Vendor records in Dynamics 365 Business Central collect problems that create payment risk: missing payment terms or method, duplicates set up by different people, blocked vendors with balances, and vendors who owe you money. These usually surface only when a payment run goes wrong.
What popdock provides
--
Ask for the audit and it reads your Dynamics 365 Business Central vendors and checks each for missing payment terms or method, missing contact details or country, blocked status with a balance, possible duplicates by name, email or phone, and negative balances. For each duplicate group it reads the last year of posted invoices to show which record is actually in use. You get a count and table per rule, a note if results hit the read limit, and nothing is changed.
Business outcome
---
Vendor data is cleaned up before the next payment run, with duplicates resolved toward the record actually in use.
scenario
-
When a customer asks whether you can supply an item, the answer in Dynamics 365 Business Central is spread across inventory, open sales orders, incoming purchase orders, variants and vendor lead times. Piecing it together while the customer waits is slow and often wrong.
What popdock provides
--
Name the item and it finds it in Dynamics 365 Business Central, saying first if it is blocked. It reads on hand, committed and on order quantities, then builds a dated timeline of order shipments going out and expected receipts coming in, with a running available quantity and the first date it goes negative. Variants, supplying vendors with lead times, and catalog alternatives when there is no vendor are listed. It notes that availability is company-wide and changes nothing.
Business outcome
---
You give customers a reliable availability answer, with dates, while they are still on the line.
scenario
-
Raising a purchase order in Dynamics 365 Business Central means finding the vendor, looking up each item and its last cost, checking the vendor actually supplies it and making sure the same items are not already on order. Missing one check leads to double ordering or the wrong price.
What popdock provides
--
Name the vendor, the items and quantities and optionally a receipt date, and it resolves the vendor and each item in Dynamics 365 Business Central, stopping on blocked vendors or items and on unclear matches. It warns when the vendor has no record for an item and when an item already has an open order line, and uses the last direct cost unless you give one. You preview the full order with warnings, it is created once only after you confirm, then read back with its number and total.
Business outcome
---
Purchase orders go out at the right cost, to a vendor that supplies the items, without double ordering.
scenario
-
Billing a customer directly in Dynamics 365 Business Central means checking they are not blocked, finding the right items, G/L accounts or resources for each line and making sure the same invoice was not already raised. A duplicate invoice damages trust and takes a credit memo to undo.
What popdock provides
--
Name the customer and the lines, whether items, services billed to an account or resource time, and it checks the customer is not blocked for invoicing in Dynamics 365 Business Central. Each line is resolved, with accounts required to be open posting accounts. Open and recently posted invoices are checked for a matching reference or total and flagged as possible duplicates. You preview the invoice, it is created once after you confirm, then read back and reported as a draft still to be posted.
Business outcome
---
Draft invoices are raised against the right customer and lines, with duplicate billing caught before it happens.
scenario
-
Taking a sales order in Dynamics 365 Business Central should involve checking the customer is not blocked, stock can cover each line, and the order will not push the account over its credit limit or past overdue invoices. Under pressure, those checks get skipped.
What popdock provides
--
Name the customer, the items and optionally a delivery date, and it checks in Dynamics 365 Business Central that the customer is not blocked for shipping, resolves each item, refuses blocked ones and compares quantities with available stock. It warns when the order would exceed the credit limit or the customer has invoices over 30 days overdue. You see every warning in the preview, the order is created once only after you confirm, and it is read back with any failed line.
Business outcome
---
Sales orders are placed with stock and credit checked, so problems are visible before the customer is promised anything.
scenario
-
Building a sales quote in Dynamics 365 Business Central means finding the customer, looking up each item by number or description and getting prices and validity dates right. A blocked item or a mistyped number in a quote leads to awkward corrections after the customer has seen it.
What popdock provides
--
Name the customer and the items with quantities, and optionally a valid-until date, 30 days by default, and it resolves the customer and each item in Dynamics 365 Business Central, stopping on blocked customers, blocked items or unclear matches. Item prices are used unless you give your own. You preview the quote with line amounts and total, it is created once after you confirm, and it is read back with its number and any failed line. No order or invoice is created.
Business outcome
---
Accurate quotes reach customers faster, with blocked items and wrong lookups caught before they go out.
scenario
-
Judging which marketing campaigns paid off means comparing campaign costs in Dynamics 365 Business Central with the opportunities each one produced and how many were won. Opportunities cannot be filtered by campaign, so the matching usually ends up in a spreadsheet.
What popdock provides
--
Give a start date, one year ago by default, and it reads the campaigns that started since then and the opportunities expected to close in that time from Dynamics 365 Business Central. Opportunities are matched to campaigns, counting won, lost and open deals and their value. You get a comparison table, the best and worst campaigns by value won per unit of cost, and active campaigns with no opportunities. It warns when the opportunity read may be incomplete and changes nothing.
Business outcome
---
You see which campaigns produced real pipeline and revenue for their cost, to guide the next budget decision.
scenario
-
Knowing whether you will have enough cash in the coming weeks means adding bank balances to customer invoices due and subtracting vendor invoices due, week by week. Doing it from Dynamics 365 Business Central screens is slow, and overdue receivables make the picture look rosier than it is.
What popdock provides
--
Choose how many weeks to look ahead, four by default, and it reads open bank balances, customer invoices due and vendor invoices due from Dynamics 365 Business Central. Overdue receivables are shown separately instead of being counted as cash in week one, while overdue payables count as due now. You get a week-by-week table per currency, open orders as an indicative pipeline, and the first week cash falls below minimum balances. It states this is a due-date forecast and changes nothing.
Business outcome
---
You see cash shortfalls weeks ahead, with overdue receivables kept out of the numbers you rely on.
scenario
-
Chasing overdue customers works best when you start with the oldest, largest debts, but Dynamics 365 Business Central shows invoices one at a time. Working out who to call first means aging every invoice, checking reminders and last payments, and spotting credits that already offset the debt.
What popdock provides
--
Set a minimum days overdue, one by default, and it reads open invoices from Dynamics 365 Business Central, ages them into four buckets per customer, and for the top 15 adds credit limit, contact details, reminder level, finance charges, last payment and unapplied credits. Customers are ranked by the oldest debt, moved up with no payment in 90 days and down when a credit covers most of it. The top five get a suggested next action. Currencies are never mixed, and no customer is blocked or changed.
Business outcome
---
Your collections team starts each day with a ranked worklist, chasing the debts most likely to go bad first.
scenario
-
Before a call with a customer, you need their balance, credit headroom, overdue invoices, open orders, recent payments, reminders and account notes. In Dynamics 365 Business Central that means visiting a different page for each, and something important is easy to miss.
What popdock provides
--
Name the customer and it identifies them in Dynamics 365 Business Central, listing candidates if several match. It reads balance and credit headroom, open invoices with days overdue, unapplied credit memos, open quotes and orders including late ones, the last payments, reminders, finance charges and comments. You get a one-page review ending with at most three things that need doing. Empty sections are marked none, currencies are kept apart, it does not guess why a customer has not paid, and nothing is changed.
Business outcome
---
You go into every customer conversation with a complete one-page account picture and a short list of what to address.
scenario
-
Fixed asset registers in Dynamics 365 Business Central go stale: assets fully depreciated but still listed as active, items with no custodian or location, and equipment still assigned to people who have left. Auditors find these problems faster than the finance team does.
What popdock provides
--
Optionally name an asset class, and it reads your active fixed assets in Dynamics 365 Business Central and checks for fully depreciated assets still active, assets with cost but no depreciation set up, missing custodians, locations or serial numbers, and blocked assets marked active. It cross-checks custodians against inactive employees and location codes against real locations. You get a register summary by class, a table per check and assets held by leavers. Nothing is changed.
Business outcome
---
Your fixed asset register is audit-ready, with leavers' equipment and incomplete records already identified.
scenario
-
Deciding what to reorder in Dynamics 365 Business Central means comparing each item's stock, sales orders and incoming purchase orders with its reorder point, then working out who to buy from. Doing it item by item takes hours and stock-outs still slip through.
What popdock provides
--
Optionally name a vendor, and it reads unblocked items from Dynamics 365 Business Central and projects stock as on hand minus sales orders plus purchase orders. Items at or below their reorder point, or heading negative with no reorder point, are kept and matched to vendors with lead times and last costs. You get suggested quantities grouped by vendor with a total per vendor. It notes that minimum order quantities and pack sizes are ignored, and it creates no purchase orders.
Business outcome
---
Buyers get a vendor-by-vendor reorder list with quantities and costs, cutting the risk of stock-outs.
scenario
-
Knowing where a project stands in Dynamics 365 Business Central means comparing budget with usage on every task, checking what is billable but not yet invoiced, and adding up hours from timesheets. Heading and total lines make it easy to double count.
What popdock provides
--
Name the job and it finds it in Dynamics 365 Business Central, noting when the end date has passed while it is still open. It reads posting tasks only, so headings and totals are not counted twice, and compares cost and price budgets with usage, lists tasks over budget and shows billable amounts not yet invoiced. Timesheet hours are totalled by resource and status, with unposted hours noted. Nothing is changed.
Business outcome
---
Project managers see budget overruns, unbilled work and hours booked on a job in one review.
scenario
-
Understanding where purchase spend goes means netting posted invoices against credit memos and grouping by vendor and by what was bought. In Dynamics 365 Business Central that is a manual export, and concentration with a few vendors or one-off suppliers is hard to see.
What popdock provides
--
Give a period, the current month to date by default, and it reads posted purchase invoices and credit memos from Dynamics 365 Business Central and works out net spend by vendor. Lines are grouped by type, item and G/L account, with credits subtracted. You get a headline, the top 15 vendors with their share, the top items and accounts, the share held by the top five vendors and vendors used only once. Each currency gets its own table, and nothing is changed.
Business outcome
---
You see where purchase money goes and how concentrated it is, ready for supplier reviews and negotiations.
scenario
-
Customers chase late orders before you do when the sales backlog in Dynamics 365 Business Central is not reviewed. Finding late lines, checking whether stock can cover them and when the next delivery arrives means switching between orders, items and purchase lines.
What popdock provides
--
Optionally name a customer, and it reads open sales orders and their outstanding lines from Dynamics 365 Business Central, flagging lines past their shipment date. Each item's stock is compared with total demand across open orders, and short items show the next expected receipt. You get a summary, late lines with days late, short items, and lines that can ship now grouped by order. It notes that stock is company-wide, suggests rather than makes date changes, and changes nothing.
Business outcome
---
Late and short orders are visible before customers chase them, and lines that can ship today are clear.
scenario
-
Sales reviews need net sales by customer, salesperson and item, compared with the previous period. Building that from Dynamics 365 Business Central means exporting invoices and credit memos, netting them and calculating margins by hand each month.
What popdock provides
--
Give a period, the current month to date by default, and it reads posted sales invoices and credit memos from Dynamics 365 Business Central and works out net sales by customer and salesperson. Item lines are netted by quantity and amount, with an estimated margin where unit cost is recorded. The same length of prior period is read for comparison, including customers who bought then but not now. Each currency gets its own table, it says when results hit the read limit, and nothing is changed.
Business outcome
---
Sales leaders get a period-over-period performance report, including lapsed customers, without building it by hand.
scenario
-
Pipeline reviews in Dynamics 365 Business Central often focus on the total and miss the deals that matter: closes already overdue, deals stalled far beyond their usual cycle and value that is likely to close this month. Spotting them means checking every opportunity against its sales cycle.
What popdock provides
--
Optionally name a salesperson, and it reads open opportunities from Dynamics 365 Business Central with their sales cycles and stages. It totals estimated and current value by status and salesperson, weights the pipeline by each stage's chance of success, and finds overdue closes, deals closing in the next 30 days and deals open more than twice their typical cycle. You get a headline, a view by salesperson and lists of deals that need attention. Nothing is changed.
Business outcome
---
Sales managers see a weighted pipeline and know exactly which stalled or overdue deals need attention.
scenario
-
Before a supplier call or payment decision, you need to know what you owe, what is on order, what credits are unapplied and whether any deliveries are late. In Dynamics 365 Business Central that information sits on several different pages for each vendor.
What popdock provides
--
Name the vendor and it identifies them in Dynamics 365 Business Central, listing candidates if several match. It reads balance, terms, open invoices with days to due, unapplied credit memos, open purchase documents with late receipts, the last payments, comments and the items they supply. You get a one-page review ending with at most three things that need attention, a flag if a blocked vendor still has a balance, and amounts kept in their currency. Nothing is changed.
Business outcome
---
You walk into every supplier conversation knowing exactly what is owed, on order and overdue.
scenario
-
Entering a general journal in Dynamics 365 Business Central means checking every account can take a direct posting, making sure debits equal credits for each document, and keying the lines without errors. An unbalanced batch or a blocked account is only discovered at posting time.
What popdock provides
--
Give a batch name, the entries and optionally a posting date, and it checks the batch name is not already in use in Dynamics 365 Business Central, then confirms every G/L account is an open posting account and every customer, vendor or bank line exists. Debits must equal credits for each document or it stops and shows the difference. You preview every line, the batch and lines are created only after you confirm, and the totals are read back. The batch is never posted.
Business outcome
---
Journals arrive in Business Central balanced and against valid accounts, ready for review and posting.
scenario
-
Entering a vendor bill in Dynamics 365 Business Central means checking it has not already been entered, matching it to the purchase order and finding the right items or expense accounts. A repeated invoice number is only rejected at posting, after the work is done.
What popdock provides
--
Give the vendor invoice number, vendor and lines, and it resolves the vendor and checks both posted and draft invoices in Dynamics 365 Business Central for the same invoice number, stopping on a match. Lines are matched to open purchase orders where possible, using the order cost and noting price differences, and expense accounts must allow direct posting. You preview the invoice, it is created once after you confirm, and it is read back with a note if the total differs from the bill.
Business outcome
---
Vendor bills are entered once, matched to orders where possible, with duplicate invoice numbers stopped up front.
scenario
-
Crediting a customer in Dynamics 365 Business Central means reading the posted invoice, working out what was already credited, and making sure the new credit does not exceed what was invoiced. Two people crediting the same invoice can easily give away more than intended.
What popdock provides
--
Name the posted invoice, what to credit and the reason, and it reads the invoice lines from Dynamics 365 Business Central along with posted and draft credit memos already applied to it. No line is ever credited beyond invoiced minus already credited, and a fully credited invoice stops the process. If a draft credit memo already exists, it offers to amend that instead. You preview the credit with totals, it is created once after you confirm with the reason recorded, and it is read back as a draft still to post.
Business outcome
---
Customer credits are issued accurately, with no risk of crediting an invoice twice or beyond what was billed.
scenario
-
Logging a new opportunity in Dynamics 365 Business Central means finding the contact or creating one, picking the right salesperson and checking a colleague has not already logged the same deal. Duplicate opportunities inflate the pipeline and confuse forecasts.
What popdock provides
--
Describe the opportunity, the contact and its value, and it finds the contact in Dynamics 365 Business Central, offering to create one as part of the confirmation if none exists. Open opportunities at the same company are checked for a similar description. The contact's salesperson is used unless you name someone, and the closing date defaults to 90 days out. You preview everything, at most one contact and one opportunity are created after you confirm, and the result is read back.
Business outcome
---
New deals enter the pipeline once, against the right contact and salesperson, keeping forecasts trustworthy.
scenario
-
When someone leaves, their assets, projects, timesheets, customers and open deals in Dynamics 365 Business Central need new owners. Without a checklist, equipment goes unreturned, timesheets stay open and accounts are left with nobody responsible.
What popdock provides
--
Name the employee and it finds them in Dynamics 365 Business Central, then lists the fixed assets they look after, open jobs they run, unposted timesheet lines and, if they sell, their customers, open opportunities and campaigns. The handover list is grouped by area with counts, and it states which items must be reassigned directly in Business Central. Only after you confirm is the employee set to Inactive, with no other fields changed, and the status is read back.
Business outcome
---
Departures are handled with a complete handover list, so nothing the employee owned is left without an owner.
scenario
-
Setting up a new customer in Dynamics 365 Business Central means checking they do not already exist under a slightly different name, entering address and contact details, and adding their main contact. A duplicate customer splits balances and statements across two records.
What popdock provides
--
Give the customer name and details, and it searches Dynamics 365 Business Central customers by name and email and contacts by company name, showing anything that could be the same organisation; an exact name match needs an explicit yes. It asks for essentials such as a country and an email or phone, and checks any salesperson named. You see the customer and contact exactly as they will be created, at most one of each is created after you confirm, and the credit limit is left unset unless you give one.
Business outcome
---
New customers are set up once with complete details, ready to quote and invoice without duplicate accounts.
scenario
-
Adding a new hire in Dynamics 365 Business Central is quick, but sales and purchasing staff also need a salesperson or purchaser code, and a code already in use causes confusion on documents and reports. Duplicate employee records cause problems of their own.
What popdock provides
--
Give the full name and details, and it checks Dynamics 365 Business Central for an existing employee with the same name and shows any matches before going on. It collects the job title, email, phone and start date, and if the role involves selling or buying, proposes an unused salesperson or purchaser code. You preview both records, at most one employee and one code are created after you confirm, and both are read back with their numbers.
Business outcome
---
New hires are set up with the right records and codes from their first day, without duplicates.
scenario
-
Onboarding a supplier in Dynamics 365 Business Central means checking they are not already set up under another name or tax number, entering their details and adding their main contact. A duplicate vendor risks paying the same invoice twice.
What popdock provides
--
Give the vendor name and details, and it searches Dynamics 365 Business Central vendors by name and email and contacts by company name, and an exact name or tax registration match needs an explicit yes. It asks for a country and an email or phone if missing. You see the vendor and contact exactly as they will be created, at most one of each is created after you confirm, and the new vendor is read back with a reminder to set payment terms, method and posting groups in Business Central.
Business outcome
---
Suppliers are onboarded once with clean details, removing a common cause of duplicate payments.
scenario
-
Planning a vendor payment run in Dynamics 365 Business Central means listing invoices due, netting unapplied credits, holding blocked vendors and checking there is enough cash in the bank. Getting it wrong means either late payments or an overdrawn account.
What popdock provides
--
Give a pay-by date, 14 days ahead by default, and it reads open vendor invoices due by then and unapplied credit memos from Dynamics 365 Business Central, netting credits per vendor and never across currencies. Vendors blocked for payment are marked HOLD. Totals to pay are split into overdue and due, then compared with cash available above minimum balances, with a suggested order if cash is short. It only proposes payments; nothing is paid or changed.
Business outcome
---
Payment runs are planned against real cash, with credits netted and blocked vendors held before money moves.
scenario
-
Registering a new fixed asset in Dynamics 365 Business Central means checking it is not already recorded, picking a class that exists, and assigning a real location and an active employee as custodian. Mistakes here surface later as audit findings.
What popdock provides
--
Describe the asset and its details, and it checks Dynamics 365 Business Central for existing assets by serial number and description, showing matches before going on. The class is checked against classes in use, the location against real locations, and the custodian must be an active employee; it asks if no class is given. You preview the record, at most one asset is created after you confirm, and it is read back with a reminder to set acquisition cost and depreciation in Business Central.
Business outcome
---
New assets are registered once with a valid class, location and custodian, keeping the register audit-ready.
scenario
-
Raising a credit memo against a vendor invoice for returns or a price dispute means reading the posted invoice, checking what has already been credited and making sure the vendor's credit memo was not already entered. Over-crediting or entering it twice throws off what you owe.
What popdock provides
--
Name the posted purchase invoice, what to credit and optionally the vendor's credit memo number, and it reads the invoice lines from Dynamics 365 Business Central with posted and draft credits already applied. It never credits more than invoiced minus already credited, flags a vendor credit memo number already entered and offers to amend an existing draft instead. You preview the credit lines and total, it is created once after you confirm, and it is read back.
Business outcome
---
Vendor credits are recorded accurately and only once, so payables reflect what you really owe.
scenario
-
A general journal batch in Dynamics 365 Business Central can look fine until posting fails on a blocked account, or worse, posts a duplicate. Checking balance, accounts, dates, blank fields and repeated document numbers by hand is tedious and easy to rush.
What popdock provides
--
Name the batch and it reads its lines and per-document totals from Dynamics 365 Business Central, then checks that each document balances, every G/L account is an open posting account, dates are not in the future or over 60 days old, descriptions and document numbers are filled in, and no lines are duplicated. Each document number is also checked against the ledger for earlier posting. You get a pass or fail per check, the problem lines and a one-line verdict. Nothing is changed or posted.
Business outcome
---
Journals are checked before posting, so blocked accounts, duplicates and repeats are caught while they are easy to fix.
scenario
-
Draft reminders and finance charge memos in Dynamics 365 Business Central are often prepared days before they are issued. In the meantime customers pay, and sending a reminder for an invoice already settled, or charging interest twice, damages the relationship.
What popdock provides
--
Optionally name a customer, and it reads the draft reminders and finance charge memos with their lines from Dynamics 365 Business Central. Each invoice line is checked against the current remaining amount to catch payments since the draft was made, each reminder against its terms for level limits and minimum amounts, and each finance charge against issued memos for interest already charged. You get a ready to issue list, a needs fixing list with reasons and total fees. Doubtful lines go to needs fixing, and nothing is issued or changed.
Business outcome
---
Only accurate reminders reach customers, with paid-off invoices and repeat interest charges caught before issue.
scenario
-
Closing a week's time in Dynamics 365 Business Central means finding who has not submitted, which lines wait for approval, which were rejected and why, and who booked nothing at all. Chasing it person by person delays billing and payroll.
What popdock provides
--
Give a date range, the last full week by default, and it reads timesheet lines from Dynamics 365 Business Central and totals hours by resource and status. Rejected lines are shown with the comment explaining why, and submitted lines are grouped by approver. Resources set to use timesheets who booked no time are listed with their approver, and chargeable hours not linked to a job are called out. If there are no lines, it lists who was expected to book time. Nothing is changed.
Business outcome
---
Timesheets are closed out faster, with every missing, rejected or waiting entry assigned to someone to chase.
scenario
-
Adding a bank account in Dynamics 365 Business Central means making sure the account number or IBAN is not already set up and that the IBAN is in a valid format. A duplicate or mistyped bank account causes reconciliation headaches and misdirected payments.
What popdock provides
--
Give the account name and details, and it searches Dynamics 365 Business Central bank accounts by name and account number and compares IBANs, stopping on an exact match. It asks for an account number or IBAN if neither is given, and checks the IBAN has a country prefix and check digits. You preview the record, at most one bank account is created after you confirm, and it is read back with a reminder to set up posting groups and reconciliation in Business Central.
Business outcome
---
New bank accounts are added once with a valid IBAN, avoiding duplicates and payment mistakes.
scenario
-
Setting up a new warehouse or updating a site's address in Dynamics 365 Business Central means checking whether the location already exists, getting the code format right and editing only what has changed. Overwriting the wrong location's details confuses shipping and receiving.
What popdock provides
--
Give a location code or name and the details, and it looks the location up in Dynamics 365 Business Central: one match means an update, several means it lists them and stops, none means a create with an upper case code of up to 10 characters. For an update you see a before-and-after table and only the changed fields are written; for a create you see the full record. Nothing changes until you confirm, and the result is read back.
Business outcome
---
Locations are created or updated correctly, so addresses and contacts used in shipping and receiving stay accurate.
scenario
-
When a customer asks about an order, the answer is scattered across Dynamics 365 Business Central: the open order, one or more posted invoices, credit memos, ledger entries showing what was paid, plus comments and attachments. Piecing that together means searching each screen by a different number and hoping you did not miss a partial shipment or a credit.
What popdock provides
--
Give a document number, and it searches Dynamics 365 Business Central for a matching quote, order, invoice or credit memo, including invoices that carry it as the order number or customer reference, and says which matched. It compares ordered, shipped and invoiced quantities line by line, follows each invoice into the customer ledger for payments and applications, and finds credit memos applied against it. You get a dated timeline, the amounts still open, and the comments and attachments. Nothing is created or changed, and if nothing matches it asks whether the number belongs to a purchase document.
Business outcome
---
You answer where an order stands, from order to payment, in one pass instead of opening a dozen Business Central screens.
scenario
-
Changing a customer in Dynamics 365 Business Central sounds simple until it involves credit. Raising a limit or blocking an account should be backed by the balance, overdue invoices and recent payments, and a block quietly stops open orders from shipping. Contact changes, meanwhile, belong on the person's contact record, not the customer card.
What popdock provides
--
Describe the change and name the customer, and it finds the one matching customer in Dynamics 365 Business Central, stopping if several match. For credit limit or block changes it first gathers the balance, overdue invoices, payments from the last 180 days and open orders a block would stop, and warns you about those orders. Changes to a person are routed to their contact record. You see a before and after table, nothing is written until you confirm, only the changed fields are sent, and the customer is read back so you can see the new values.
Business outcome
---
Credit and contact changes land on the right record, backed by evidence, with no surprise held orders.
scenario
-
Editing a vendor in Dynamics 365 Business Central carries more risk than it looks. Blocking a vendor can hold up open invoices and purchase orders, and a request to change an email, phone number or address is a well known route for payment fraud. Doing it by hand means checking open documents and recent notes before you touch the card.
What popdock provides
--
Describe the change and name the vendor, and it resolves the single matching vendor in Dynamics 365 Business Central, stopping if several match. Before a block it lists the open invoices and purchase orders the block would hold up. For contact or address changes it shows recent vendor notes and reminds you to verify the change with the vendor by a known phone number. You see a before and after table, nothing is saved until you confirm, only changed fields are sent, and the vendor is read back afterwards.
Business outcome
---
Vendor details change safely, with blocked documents visible up front and a fraud check built into every contact change.
scenario
-
Repricing items in Dynamics 365 Business Central usually means exporting to a spreadsheet, working out each new price from cost or a target margin, and typing them back one by one. It is easy to price something below cost, apply a far bigger change than intended, or forget that open quotes and orders keep their old prices.
What popdock provides
--
Choose items by number, category or vendor and give a rule, such as a percentage change, a fixed price or a target margin over cost, and it works out each new unit price in Dynamics 365 Business Central, rounded to two decimals. Blocked items are left out and named. Any price below cost or any change over 25 percent either way is flagged. You review a full before and after table, can drop rows, and nothing changes until you confirm. Only the unit price is updated, then every item is read back to report what changed and what failed.
Business outcome
---
Price changes go through in one reviewed batch, with below-cost and outsized changes caught before they reach customers.
scenario
-
After a move from Dynamics GP to Dynamics 365 Business Central, some active customers inevitably never made it across. Finding them means comparing two customer lists whose IDs differ in case and padding, then keying each missing one in by hand, with the risk of exceeding ID length limits or forgetting that open balances do not come with them.
What popdock provides
--
Name one customer or let it check every active one, and it compares Dynamics GP with Dynamics 365 Business Central, matching IDs regardless of case and spacing. IDs too long for Business Central are set aside, and customers with a GP balance are flagged because the balance does not move with them. You confirm the list, or a subset, before anything is created, and it writes only to Business Central, up to a limit you set. Each new customer is read back, and you get the GP payment terms and class for each so you can finish the setup.
Business outcome
---
Missing customers reach Business Central with their contact and credit details, and you know exactly what setup is left.
scenario
-
Proving a customer migration from Dynamics GP to Dynamics 365 Business Central is right means checking names, payment terms, credit limits, salespeople, contact details and hold status customer by customer. GP pads IDs and stores phones as padded digits, so a naive comparison flags hundreds of false differences and buries the real ones.
What popdock provides
--
Name a customer or check every active one, and it reads both Dynamics GP and Dynamics 365 Business Central, matching IDs regardless of case and padding. It compares names, terms, credit limits, salespeople, city, state, email, phones on digits only, and GP holds against Business Central blocks. When a whole group of customers has terms renamed the same way, it reports that once as a mapping. You get counts, a table of differences, missing customers, and Business Central customers created after go-live. It warns if a list may be truncated, and nothing is changed in either system.
Business outcome
---
You sign off a customer migration with every real difference listed and the formatting noise filtered out.
scenario
-
Checking that inventory arrived in Dynamics 365 Business Central from Dynamics GP means comparing descriptions, units of measure, costs, item types and quantities on hand for every item. Item types use different names in each system, GP splits quantities by site, and a long list of small differences hides the few gaps that are worth real money.
What popdock provides
--
Name one item or check all of them, and it compares Dynamics GP items with Dynamics 365 Business Central, leaving out discontinued items but counting them. It totals GP quantities across sites where needed, maps GP item types to their Business Central equivalents, and flags cost differences over one percent. Quantity gaps are ranked by their value at current cost, so the costliest come first. If Business Central shows zero for everything, it says opening quantities have not been posted yet instead of listing every item. Both systems are only read.
Business outcome
---
Inventory sign-off focuses on the quantity gaps that matter most in value, not a wall of rounding noise.
scenario
-
A vendor that is missing or set up differently in Dynamics 365 Business Central after a Dynamics GP migration can stop payments on the first day live. Checking names, terms, hold status, contacts and phone numbers vendor by vendor is slow, and the most urgent case, a missing vendor that still has an open balance, is easy to overlook.
What popdock provides
--
Name a vendor or check every active one, and it compares Dynamics GP vendors with Dynamics 365 Business Central, ignoring inactive and temporary vendors and matching IDs regardless of case. It compares names, payment terms, holds against blocks, contacts, city, state, email and phones on digits only, and reports a terms renaming once as a mapping. Missing vendors are listed with their GP balance, because one with money owed blocks the payables cutover. Vendors created after go-live are shown separately, and nothing is changed in either system.
Business outcome
---
Payables cutover goes ahead knowing every vendor with an open balance exists in Business Central and matches.
scenario
-
Proving open payables moved correctly from Dynamics GP to Dynamics 365 Business Central means comparing each vendor's balance, then digging through invoices and ledger entries to explain every difference. Signs run the opposite way in each system, some migrations post under the voucher number, and an invoice left behind will simply never get paid.
What popdock provides
--
Name a vendor or check all vendors with a balance, optionally as of the go-live date, and it compares each balance in Dynamics GP and Dynamics 365 Business Central, correcting for the opposite sign convention. For every vendor out by more than a cent it matches open documents by invoice number, then voucher number, and says which are missing, extra or different. Summary-level migrations are recognized, any unexplained remainder is stated rather than guessed, and open GP invoices due within 14 days that are missing are called out. Nothing is written.
Business outcome
---
You prove the payables carryover vendor by vendor and catch invoices that would otherwise go unpaid after go-live.
scenario
-
Purchase orders still open in Dynamics GP at go-live need to exist in Dynamics 365 Business Central, or goods arrive with nothing to receive them against. Checking means matching order numbers that may have been renumbered, comparing vendors, remaining amounts and promised dates, and allowing for tax that one side includes and the other does not.
What popdock provides
--
Name a vendor or check every vendor, and it reads open purchase orders in Dynamics GP, including those on hold, and finds them in Dynamics 365 Business Central by order number, then by vendor order number, then by vendor and amount within one percent, marking those as probable. It compares vendor, remaining amount with tax allowed for, expected date and currency. Missing orders are listed soonest receipt first, and if none were migrated it lists what buyers must re-enter. Neither Dynamics GP nor Business Central is written to.
Business outcome
---
Buyers know which open orders need re-entering before the goods turn up, soonest receipts first.
scenario
-
Proving that customer balances carried from Dynamics GP into Dynamics 365 Business Central means comparing every customer and then tracing each difference to documents. GP stores payments and credits as positive while Business Central stores them as negative, and post go-live activity muddies current balances, so manual checks take days.
What popdock provides
--
Name a customer or check all customers with a balance, optionally as of the go-live date, and it compares each balance in Dynamics GP and Dynamics 365 Business Central. For any customer out by more than a cent it lines up open documents by number, flipping signs on payments, credits and returns, and shows what is missing, extra or different. Summary-level migrations count as in balance, any unexplained remainder is reported rather than guessed, and nothing is written to either system.
Business outcome
---
Receivables carryover is proven customer by customer, with every difference traced to the documents behind it.
scenario
-
Tying out the Dynamics GP trial balance to Dynamics 365 Business Central is a standard migration check, but GP accounts carry several segments while Business Central keeps the main account and moves the rest to dimensions. Rolling up dozens of GP accounts, handling balance sheet and income statement periods correctly and matching dates is error-prone spreadsheet work.
What popdock provides
--
Give the fiscal year, period, as-of date and year start, and it builds the Dynamics GP trial balance, adding beginning balances only for balance sheet accounts, and rolls accounts up by main segment. It then totals Dynamics 365 Business Central ledger entries for each matching account and lists differences largest first, unmatched accounts on both sides, and whether each side nets to zero. It warns when dates do not line up or a total may be incomplete, and if the account mapping is custom it stops and asks rather than guessing. No record in either system is touched.
Business outcome
---
Controllers tie out the migrated general ledger account by account, with the largest differences surfaced first.
scenario
-
After moving from Dynamics GP to Dynamics 365 Business Central, a customer's history is split in two. Seeing whether they are buying more or less means pulling sales from both systems by month, and the migrated opening entries in Business Central make it easy to count the same invoices twice and overstate recent sales.
What popdock provides
--
Name the customer and the go-live date, and it reads Dynamics GP history up to go-live and Dynamics 365 Business Central activity since, leaving out migrated opening entries so nothing is counted twice. You get monthly sales running straight across go-live, totals before and after, open orders, quotes and invoices with due dates, and anything that changed at go-live, such as salesperson, terms or credit limit. GP sales posted after go-live are shown separately. If the go-live date is missing it asks, and nothing is changed.
Business outcome
---
Account managers see one honest sales trend for a customer across both systems, without double counting.
scenario
-
Keeping a Mailchimp audience in step with Dynamics 365 Business Central customers means exporting emails, checking each against the audience and importing the rest. Do it carelessly and you re-add people who unsubscribed, include blocked accounts, or subscribe customers who never gave consent.
What popdock provides
--
Name the audience, and optionally a salesperson, and it finds Dynamics 365 Business Central customers with an email who are not blocked and not yet in the Mailchimp audience. Anyone already present is skipped whatever their status, so unsubscribed and cleaned contacts are never re-added. New members are added as pending by default, which sends Mailchimp's double opt-in, unless you state consent was given. You confirm the list first, at most 100 are added per run, and each add is checked afterwards. Nothing in Business Central is changed.
Business outcome
---
Your audience grows with real customers while unsubscribes stay respected and consent stays clean.
scenario
-
Abandoned cart reminders go to everyone by default, including shoppers whose accounts are blocked, overdue or already over their credit limit in Dynamics 365 Business Central. Checking each cart against the account by hand is slow, so most teams either chase every cart or none.
What popdock provides
--
Set a lookback period and an optional minimum cart value, and it lists open Mailchimp carts and looks each shopper up in Dynamics 365 Business Central by email. Each cart is labelled new shopper, blocked, overdue, over credit limit or good standing, with the credit test skipped when currencies differ. Carts are sorted by value, checkout links are shown only for carts worth chasing, and the rest are routed to the salesperson. Carts with no email are listed as unidentifiable. Nothing is sent or changed.
Business outcome
---
You chase the carts worth chasing and hand risky accounts to sales instead of sending them a discount.
scenario
-
Your most engaged Mailchimp subscribers are often warm prospects that sales has never heard of. Finding them means exporting highly rated members and checking each email against customers and contacts in Dynamics 365 Business Central, a job that rarely gets done.
What popdock provides
--
Name the audience and a minimum rating, and it reads subscribed Mailchimp members at or above that rating and checks each email against Dynamics 365 Business Central customers, then contacts. You get counts for each group and a lead list of members not in Business Central, sorted by rating and click rate, plus who already owns the ones that are contacts. If no one meets the rating it suggests a lower one. It reads only, and if you later ask to create contacts it confirms the list and job title first.
Business outcome
---
Sales gets a ready lead list of engaged subscribers nobody in Business Central is working yet.
scenario
-
Before you call or email someone, you want to know both sides of the relationship: are they subscribed, do they open campaigns, have they abandoned a cart, and do they owe money in Dynamics 365 Business Central. Getting that means logging into Mailchimp and Business Central and searching each by email.
What popdock provides
--
Give an email address, and it pulls Mailchimp audience memberships, status, tags, rating, recent campaign opens, store spend and open carts, then the Dynamics 365 Business Central customer or contact with balances, unpaid invoices and open orders. Emails are matched exactly, never on part of an address, and several matching customers are shown separately. A short summary flags overdue invoices, blocked accounts, abandoned carts or an unsubscribed status. Neither Mailchimp nor Business Central is edited.
Business outcome
---
You walk into any conversation knowing both the marketing engagement and the account standing behind one email.
scenario
-
Mailchimp reports the store revenue it attributes to a campaign, but finance trusts what Dynamics 365 Business Central actually invoiced. Comparing the two means listing the campaign's buyers, finding each as a customer and totalling their invoices in the weeks after the send.
What popdock provides
--
Name the campaign and a window after the send, and it reads Mailchimp's headline numbers and the orders it attributes to the campaign, then totals what Dynamics 365 Business Central invoiced each buyer in that window. You see both figures side by side, buyer by buyer, along with buyers not found in Business Central. Different currencies are never added together, and the report states that invoices in the window show correlation, not proof. Both systems are read and left as they are.
Business outcome
---
You put a finance-grade revenue figure next to a campaign, with honest caveats about attribution.
scenario
-
When a customer who spends heavily unsubscribes from your emails, their account manager should know. Without help, unsubscribes sit in Mailchimp while sales figures and owners sit in Dynamics 365 Business Central, and nobody connects the two until the customer has gone quiet.
What popdock provides
--
Set a lookback period, and it lists recent Mailchimp unsubscribes, keeping only the latest per email, then looks each one up in Dynamics 365 Business Central as a customer or contact. Customers are ranked by sales, with balance due, the campaign, the stated reason and the owning salesperson's name and email. Empty reasons stay blank rather than guessed. It never resubscribes anyone and changes nothing in either system.
Business outcome
---
Account owners hear about valuable customers who unsubscribed while there is still time to follow up personally.
scenario
-
Store customers synced into Mailchimp should line up with customers in Dynamics 365 Business Central, but they drift: buyers never set up, one email shared by two accounts, cities and phones that disagree. Spotting this by hand means comparing exports and ignoring endless formatting differences.
What popdock provides
--
Pick a start date, or use the last 90 days, and it matches Mailchimp store customers to Dynamics 365 Business Central by email. Each is classed as matched, missing or ambiguous, and matched rows are checked for city, country and phone differences, comparing countries by meaning and phones on digits so formatting is never flagged. Blocked customers are noted, missing customers are sorted by spend, and runs over 200 cover the newest and say how many were left. It reports and never edits a customer.
Business outcome
---
Customer records stay aligned between the store sync and finance, with the highest-spending gaps fixed first.
scenario
-
Sending a promotion to a customer who is months overdue in Dynamics 365 Business Central sends the wrong message. Keeping a Mailchimp suppression segment current means exporting overdue accounts, checking which are audience members and adding them one by one.
What popdock provides
--
Name the audience, a static segment and a minimum overdue amount, and it finds Dynamics 365 Business Central customers with an overdue balance and an email. It stops if the segment is missing or not static, skips anyone already in it, and lists people who are not audience members since they cannot be added. You confirm the list before anything is written, each add is checked afterwards, and nothing is changed in Business Central. It only adds, and the report reminds you that customers who have since paid are not removed.
Business outcome
---
Overdue accounts stay out of promotional sends, with every addition confirmed by you first.
scenario
-
Prices set in Dynamics 365 Business Central and prices shown in Shopify drift apart as products are added and repriced. Finding the mismatches means exporting variants, matching SKUs to item numbers, and comparing prices row by row, while variants with no SKU or no matching item slip through unnoticed.
What popdock provides
--
Optionally name one SKU or a tolerance, and it reads Shopify variants and finds each item in Dynamics 365 Business Central by SKU, falling back to the barcode. Every variant whose price differs by more than the tolerance is listed, largest difference first, along with variants missing from Business Central, a count of variants with no SKU, and matched items that are blocked. SKUs are matched exactly, with near matches in a different case flagged to fix. If you say the currencies differ, it shows figures without flagging. Neither the store nor Business Central is edited.
Business outcome
---
Price mismatches between the store and the ERP surface in one list, largest first, before customers find them.
scenario
-
Keying a Shopify order into Dynamics 365 Business Central means checking it was not entered already, finding the right customer, mapping every line to an item, and working out discounts. One wrong SKU or a second entry of the same order means shipping errors and a messy credit later.
What popdock provides
--
Give the Shopify order, and optionally a customer number, and it reads the order and stops if it is canceled or already in Dynamics 365 Business Central under the Shopify reference. It matches the customer by email, refuses blocked accounts, and maps every line to an unblocked item by SKU or barcode, refusing to build a partial order. You see the full plan with discounts and the Shopify total, and nothing is written until you confirm. The order is then created and read back against the Shopify total. Nothing changes in Shopify.
Business outcome
---
Web orders reach Business Central once, with every line mapped correctly and no duplicates to unwind.
scenario
-
Shopify marks an order paid the moment the gateway captures the money, but the matching invoice in Dynamics 365 Business Central can stay open for weeks until someone applies the payment. Those invoices then show up as overdue and trigger collection calls to customers who already paid.
What popdock provides
--
Give a date range, and it reads Shopify orders marked paid and finds each posted invoice in Dynamics 365 Business Central that still has a remaining amount. For each, it pulls the Shopify payment gateway, amount and date, the details finance needs to apply the payment. Invoices are sorted by due date with past-due ones marked, and it says whether the open amount matches the payment exactly. Paid orders with no invoice are listed too. It reads only; applying payments stays with you.
Business outcome
---
Finance applies web payments quickly and stops chasing customers who have already paid.
scenario
-
Shopify orders are supposed to flow into Dynamics 365 Business Central, but integrations miss some, and nobody notices until a customer asks why nothing shipped. Checking means searching for each order by its reference in open sales documents and posted invoices, often in two formats.
What popdock provides
--
Give a date range, and it reads Shopify orders, sets canceled ones aside, and looks each up in Dynamics 365 Business Central as an open sales document or posted invoice by the Shopify reference, with and without the hash sign. It learns which format matches and uses it first. Missing orders are listed oldest first with totals and status. If nothing matches at all it warns the reference may be stored elsewhere instead of calling everything missing, and it flags a possibly truncated range. It only looks; nothing is entered for you.
Business outcome
---
Orders that never reached Business Central are caught early, oldest first, before customers start asking.
scenario
-
Every refund issued in Shopify should have a matching credit memo in Dynamics 365 Business Central, or revenue and receivables are overstated. Matching them by hand is slow because one order can have several refunds, some refunds have no lines, and the amounts must include tax.
What popdock provides
--
Give a date range, and it reads Shopify refunds, totals each from its lines plus tax, and looks for posted credit memos in Dynamics 365 Business Central by order reference, ignoring canceled ones. Several refunds on one order are paired by amount, then date. You get refunds with no credit memo first, then amount differences, with one-cent rounding noted as such. If nothing matches at all, it warns the reference may live in another field instead of calling everything missing. Nothing is created.
Business outcome
---
Uncredited refunds are caught before month end, so revenue and receivables stay accurate.
scenario
-
When Shopify shows more stock than Dynamics 365 Business Central actually holds, you sell what you cannot ship. Comparing quantities by SKU across hundreds of variants, while allowing for service items, packs and products set to sell when out of stock, is too slow to do often.
What popdock provides
--
Optionally name a SKU and a threshold, and it compares each Shopify variant's quantity with the matching Dynamics 365 Business Central item, found by SKU or barcode. Variants where Shopify shows more than Business Central come first because they risk overselling, with quantities on sales and purchase orders alongside. Non-inventory items and missing items are listed, as are variants that sell when out of stock while Business Central has none. Possible pack size mismatches are pointed out. Stock levels are reported, never adjusted.
Business outcome
---
You spot oversell risks before orders come in, with the riskiest variants at the top of the list.
scenario
-
A customer's online buying lives in Shopify while their balance, credit limit and blocked status live in Dynamics 365 Business Central. Seeing whether a blocked or overdue customer is still ordering online means checking both systems and matching orders to invoices yourself.
What popdock provides
--
Give an email address and a lookback period, and it finds the customer in Shopify and Dynamics 365 Business Central by exact email, stopping if either side has several matches. You get a side by side view of spend, orders, balance, credit limit and blocked status, then recent Shopify orders matched to their Business Central invoices. It flags name differences, ordering while blocked, overdue balances, balances over the limit and orders never invoiced. Lifetime spend and current balance are shown side by side, never netted. Neither customer record is edited.
Business outcome
---
You see in one view whether an online customer is in good standing before shipping or extending credit.
scenario
-
When a customer asks about a Shopify order, the answer depends on both systems: was it shipped, what tracking number, did it reach Dynamics 365 Business Central, and was it invoiced and paid there. Answering means hopping between Shopify order screens and Business Central documents.
What popdock provides
--
Give the order name or number, and it reads the Shopify order, its lines, shipments with tracking links and payments, then finds the matching sales document and posted invoice in Dynamics 365 Business Central. You get a status block for each side, a line table comparing ordered, fulfillable, shipped, invoiced and outstanding quantities, and one sentence naming anything that disagrees, such as paid online but open in Business Central. Totals are compared only when currencies agree. It only reads both systems.
Business outcome
---
You answer any question about where an order is across store and ERP in a single read.
scenario
-
Billing starts in Stripe, but the customer also needs to exist in Dynamics 365 Business Central before you can invoice or report on them there. Copying details across by hand invites duplicates when the same company already exists under a slightly different name or email.
What popdock provides
--
Give a Stripe customer ID or email, and it reads the Stripe customer, then checks Dynamics 365 Business Central by email and then by name. If a match exists it reports it and stops, never updating it. Otherwise it shows the exact name, email, phone and address it will send, lets Business Central assign the number, and asks about currency only when it differs. Nothing is created until you confirm, the customer is created once and read back, and nothing is written to Stripe.
Business outcome
---
Stripe customers appear in Business Central once, with no duplicates and no surprise edits to existing records.
scenario
-
Mirroring a Stripe invoice in Dynamics 365 Business Central means finding the customer, re-entering each line against the right revenue account, and making sure the same invoice has not been entered already. Tax is then calculated differently in each system, so totals rarely agree on the first try.
What popdock provides
--
Give the Stripe invoice and a revenue account, and it skips drafts and voids, checks Dynamics 365 Business Central for the Stripe number on existing invoices, and stops if it finds one. It finds the customer by email and plans one account line per Stripe line. You see the header and lines against the Stripe total, and nothing is created until you confirm. The invoice is left unposted, totals are compared afterwards, and a difference is explained, usually tax, rather than lines being changed. A failure partway stops and reports. Nothing is written to Stripe.
Business outcome
---
Stripe invoices land in Business Central once, as drafts you can review and post, with totals checked.
scenario
-
Stripe pays out in lump sums that arrive a few days after the sales, net of fees, so matching them to entries on the bank account in Dynamics 365 Business Central is a monthly chore. Missing deposits, duplicate postings and unrecorded fees all hide in the gap.
What popdock provides
--
Name the bank account and a date range, and it reads paid Stripe payouts and looks for each on that account in Dynamics 365 Business Central by exact amount, a few days either side of arrival. Entries mentioning Stripe or the payout are preferred, ambiguous ones are listed as possible duplicates, and no entry is used twice. You also get failed payouts and the period's Stripe fees per currency for expensing. It warns if the account looks wrong and reads only.
Business outcome
---
Stripe deposits reconcile to the bank account in minutes, with missing payouts and fees ready to post.
scenario
-
Customers created in Stripe and in Dynamics 365 Business Central drift apart: some exist only in one system, some are spelled differently, and some share an email with a duplicate. Comparing two long customer lists by hand is tedious and easy to get wrong.
What popdock provides
--
Optionally narrow by name, and it matches Stripe customers to Dynamics 365 Business Central by email, then by exact name, marking name-only matches as weaker and never matching on part of a name. You get four tables: matched, recorded differently, Stripe only and Business Central only, with duplicates flagged. If a side is empty or hits its record limit, it says so instead of guessing. It reads only and points you to a separate job to create missing customers.
Business outcome
---
Customer lists in billing and the ERP agree, with every gap and duplicate in plain view.
scenario
-
Stripe invoices should each have a posted invoice in Dynamics 365 Business Central with the same amount and payment status. When they disagree, collections chase paid customers or cash goes unapplied. Matching by hand is slow when some invoices were entered without the Stripe number.
What popdock provides
--
Give a date range, and it reads paid and open Stripe invoices and finds each in Dynamics 365 Business Central by Stripe number, falling back to the customer and an exact amount within five days, marked as matched by amount. It flags amount differences above one cent, invoices paid in one system but open in the other, and invoices found only in Stripe. Currency differences are flagged only when clear. Totals come per currency, and it warns when a read is partial. Customers are never created or edited on either side.
Business outcome
---
Payment status mismatches surface before they cause wrong collection calls or unapplied cash.
scenario
-
Refunds and credit notes issued in Stripe need matching credit memos in Dynamics 365 Business Central. Because one refund can sit behind a credit note, it is easy to count the same event twice, and refunds handled by reversing the invoice look like errors when they are not.
What popdock provides
--
Give a date range, and it reads issued Stripe credit notes and refunds, dropping refunds already covered by a credit note so nothing is counted twice. Each is looked up in Dynamics 365 Business Central by reference, then by customer and exact amount within five days, marked as matched by amount. Pending or failed refunds are listed separately, and fraudulent or duplicate refunds are noted as possibly reversed instead. Totals come per currency, and nothing is created or changed.
Business outcome
---
Every Stripe refund is accounted for in Business Central, without double counting or false alarms.
scenario
-
A customer's billing story is split between Dynamics 365 Business Central, where their invoices and balance sit, and Stripe, where subscriptions, failed charges and saved cards live. Before a call about money, pulling both together takes several logins and searches.
What popdock provides
--
Give a customer number, email or name, and it finds the customer in Dynamics 365 Business Central, asking if several match, and lists open invoices with overdue ones marked. It then finds them in Stripe by email or name and shows subscriptions, open invoices, failed charges, cards expiring within 60 days and the next invoice. A short attention list names what needs action. Amounts carry their currency, differing names are both shown, and nothing is changed.
Business outcome
---
You handle billing conversations with the full picture across both systems, and know what needs fixing.
scenario
-
A Stripe dispute does more than freeze a payment. If it is lost, an invoice that looked paid in Dynamics 365 Business Central reopens. Tracing each dispute through its charge and invoice to the customer and receivable at risk, while watching evidence deadlines, is easy to let slip.
What popdock provides
--
Optionally filter by status, and it lists Stripe disputes still in progress and traces each through its charge and invoice to the Dynamics 365 Business Central invoice and customer, finding the customer by email when there is no invoice. One table sorted by evidence deadline shows amount, reason, evidence status and the open balance. A summary gives totals per currency and how many are due within seven days, and flags invoices shown as fully paid that a loss would reopen. The report leaves every record as it was.
Business outcome
---
No dispute deadline is missed, and finance knows which paid invoices could reopen.
scenario
-
People often record time twice: on a Dynamics 365 Business Central timesheet for costing and in Teamwork.com for the project. When the two disagree, billing and payroll are both at risk, yet comparing them means lining up a resource with a Teamwork.com user and checking every day by hand.
What popdock provides
--
Name the person and a period, and it finds them in Teamwork.com, asking if several match, then matches them to a Dynamics 365 Business Central resource by name or employee email, stopping if there is none. It compares hours day by day, flags days that differ by more than a quarter hour or appear on only one side, and lists timesheet lines still open or unapproved. Entries are compared by day, not one to one. Neither timesheets nor time logs are edited.
Business outcome
---
Time discrepancies are caught before billing or payroll, one day at a time.
scenario
-
Billable hours logged in Teamwork.com should turn into invoices in Dynamics 365 Business Central, but some projects never get billed. Spotting under-billing means totalling time per project, finding the client's invoices and working out which lines were time.
What popdock provides
--
Name the client and a period, and it totals billable Teamwork.com time and value per project, noting whether hours are verified, then finds the client in Dynamics 365 Business Central and the invoices posted in the same period. It shows the gap between billable value and time billed, calls the client under-billed, over-billed or square within two percent, and lists projects with no invoice line. It notes when timing may explain a gap and skips the gap if currencies differ. No invoice is raised by this check.
Business outcome
---
You catch unbilled project work before it is written off, project by project.
scenario
-
When a job is set up in Dynamics 365 Business Central, delivery still needs a matching project in Teamwork.com. Creating it by hand means checking one does not already exist, finding the right client company and owner, and copying dates, and duplicates appear when someone does it twice.
What popdock provides
--
Give a job number, and it reads the Dynamics 365 Business Central job, stopping if it is completed or blocked. It searches Teamwork.com for a project by job number, then by description, and stops or asks if one may already exist. It matches the client company and owner without creating a company, shows the project it would create with name, dates and description, and creates nothing until you confirm. The new project is read back, and nothing in Business Central is changed.
Business outcome
---
Every Business Central job gets one Teamwork.com project, with the right client and dates and no duplicates.
scenario
-
Before a client meeting, you need two answers: do they owe money in Dynamics 365 Business Central, and how is their work going in Teamwork.com. Getting both means pulling invoices from one system and project health and budgets from the other, then working out for yourself whether the two stories conflict.
What popdock provides
--
Name the client, and it finds them in Dynamics 365 Business Central, asking if several match, and lists balance, credit limit, block status and open invoices with overdue ones first. It then finds the client company in Teamwork.com and shows each active project's status, end date, health score and budget used. An attention list flags issues such as an overdue balance on active work or a project over budget. Amounts and budgets are never added together, and nothing is changed.
Business outcome
---
Account leads see money owed and delivery health side by side before every client conversation.
scenario
-
Turning logged project time into an invoice means totalling billable hours per project in Teamwork.com, checking nothing has already been billed in Dynamics 365 Business Central, and keying lines by hand. Mistakes here mean either double billing a client or leaving hours unbilled.
What popdock provides
--
Name the client and a start date, and it totals billable Teamwork.com time per project, then finds the customer in Dynamics 365 Business Central, stopping if none matches or the account is blocked. Existing invoices mentioning the projects are shown before going further. You review a draft with one line per project, hours and rate, and nothing is created until you confirm. The invoice is created unposted and its total is checked against what you approved. A rejected line stops the run rather than guessing.
Business outcome
---
Billable time becomes a reviewed draft invoice in minutes, without double billing.
scenario
-
Jobs in Dynamics 365 Business Central and projects in Teamwork.com should line up one to one, but over time some jobs have no project, some projects have no job to post costs to, and statuses and end dates drift apart. Matching the two lists by hand means guessing which project belongs to which job.
What popdock provides
--
Optionally name a customer, and it reads Dynamics 365 Business Central jobs and Teamwork.com projects and matches them by job number in the project name or description, or by name and client, marking name-only matches as possible. You get matched pairs with status and end date mismatches over seven days, jobs with no project, and projects with no job. Dates are compared by calendar day. It reads only and points to a separate job for creating missing projects.
Business outcome
---
Delivery and finance agree on which work exists, so no project runs without a job to cost against.
scenario
-
When a client falls behind on payment in Dynamics 365 Business Central, the project team in Teamwork.com usually keeps working without knowing. Telling them means checking which invoices are overdue, finding the client's active projects and posting a careful note on each.
What popdock provides
--
Name the client and how many days overdue counts, and it finds overdue invoices in Dynamics 365 Business Central, stopping without posting if there are none. It matches the client's Teamwork.com company, stopping rather than messaging the wrong client, and finds active projects. You see the invoices, projects and exact message, which leaves out credit terms, and nothing is posted until you confirm. It posts at most one message per project and reports any failures.
Business outcome
---
Project teams learn about overdue clients while it still matters, through one approved message per project.
scenario
-
Teamwork.com client companies and Dynamics 365 Business Central customers share no common ID, so clients doing project work with no customer to bill, or blocked customers with active projects, go unnoticed until invoicing time. Comparing names by hand is thrown off by punctuation and suffixes like Inc or Ltd.
What popdock provides
--
Optionally narrow by name, and it matches Teamwork.com companies to Dynamics 365 Business Central customers by name, ignoring case, punctuation and legal suffixes, using city and country to break ties and never picking between true ties. You get matched rows with blocked customers who still have projects flagged, clients only in Teamwork.com, and customers only in Business Central with a balance. Near matches are shown as possible with a reason. No customer or company is created or edited.
Business outcome
---
Every client doing project work has a customer to bill, and blocked accounts with live projects are flagged.
scenario
-
Entering a WooCommerce order in Dynamics 365 Business Central by hand means checking it is not already there, finding or creating the customer, matching every line by SKU and handling shipping. Enter it twice, or miss a line, and fulfilment and invoicing go wrong.
What popdock provides
--
Give the order number, and it reads the WooCommerce order, stopping on pending, failed, canceled or refunded status unless you say otherwise, and stops if Dynamics 365 Business Central already has it. It matches the customer by email and only creates a new one if you confirm, then maps every line by SKU or barcode, refusing a partial order. You review the plan and nothing is written until you confirm. The order is created, checked against the WooCommerce total, and a private note with the new number is added to the web order.
Business outcome
---
Web orders enter Business Central once and completely, with the store order noting where they went.
scenario
-
Each refund issued in WooCommerce needs a credit memo in Dynamics 365 Business Central against the right invoice. Working out which lines and prices to credit, and making sure the refund was not already credited, is fiddly, and a duplicate credit overstates the customer's account.
What popdock provides
--
Give the refund ID, and it reads the WooCommerce refund and its lines and checks Dynamics 365 Business Central for credit memos already covering it, stopping if found. It finds the posted invoice for the order, credits each refunded quantity at the invoiced price, and asks which account to use for amount-only refunds. You see the plan and nothing is written until you confirm. The credit memo is created unposted, its total is compared with the refund, and a private note is added to the web order.
Business outcome
---
Web refunds become accurate draft credit memos, never twice, with a clear link back to the store.
scenario
-
WooCommerce orders that are processing or completed should all be in Dynamics 365 Business Central. Some never arrive, some arrive twice and some land with a different total, and checking order by order is slow enough that it rarely happens. Problems surface only when a customer calls.
What popdock provides
--
Give a date range, and it reads processing and completed WooCommerce orders, ignoring those not expected yet, and looks each up in Dynamics 365 Business Central as an open sales document or posted invoice by order number. Orders are classed as matched, amount differs, missing or duplicated, and you see only the exceptions, missing ones first. Currency differences are shown rather than compared raw, and truncated ranges are flagged. No order is created or altered.
Business outcome
---
Missing, duplicate and mismatched web orders are caught before they turn into fulfilment or billing errors.
scenario
-
Every WooCommerce refund should be credited in Dynamics 365 Business Central. In practice some are never credited, some are credited for a different amount, and some belong to orders that were never invoiced, and telling these apart means checking several document types per order.
What popdock provides
--
Give a date range, and it groups WooCommerce refunds by order and checks Dynamics 365 Business Central for posted and unposted credit memos, then whether the order was invoiced at all. Each order is classed as credited, credited but not posted, amount differs, not credited, or order not in Business Central, with not credited listed first since it needs action. Amounts include tax on the Business Central side. No credit memo is created.
Business outcome
---
Uncredited web refunds are found and prioritized, so customer balances and revenue stay right.
scenario
-
A store catalog drifts from the item list in Dynamics 365 Business Central: SKUs that do not exist there, blocked items still on sale, and prices or stock that disagree. Checking every product and variation by hand is not realistic for a busy store.
What popdock provides
--
Optionally name a category and a limit, and it reads published WooCommerce products, using variations rather than parents, and finds each SKU in Dynamics 365 Business Central by item number, then barcode. Each SKU is classed as no SKU, missing, blocked, price differs or stock differs, with a table per class. SKUs are matched exactly, never by name, and a pattern of same-percentage price gaps is called out as a likely tax difference. Neither the catalog nor the items are edited.
Business outcome
---
Catalog problems are found by type, from missing SKUs to blocked items still for sale.
scenario
-
Online orders and refunds sit in WooCommerce while balances, credit limits and blocks sit in Dynamics 365 Business Central. Knowing whether a web buyer is blocked, over limit or overdue means checking both systems by email, which nobody has time to do before every decision.
What popdock provides
--
Give an email address, and it gathers WooCommerce orders, spend and refunds, including guest checkouts, then finds the matching Dynamics 365 Business Central customers by exact email and lists open invoices tied to web orders. Flags appear only where true: blocked but ordering online recently, over the credit limit, overdue invoices, or not set up or set up twice. It never tries spelling variations and changes nothing.
Business outcome
---
Support and finance see a web customer's full standing at a glance before acting on an order.
scenario
-
When someone asks where a WooCommerce order stands, the answer spans the store and Dynamics 365 Business Central: was it entered, invoiced, paid, refunded and credited. Tracing it means searching several document types by order number and comparing lines yourself.
What popdock provides
--
Give the order number, and it reads the WooCommerce order, lines and refunds, then finds every Dynamics 365 Business Central document carrying it: open orders, posted invoices and credit memos. Lines are compared by SKU and quantity, and for a partly paid invoice it shows what has been applied. A one-line verdict says in sync, not yet in Business Central, amounts differ or refunded but not credited, and duplicates are flagged. Records are read, never edited.
Business outcome
---
Any web order question is answered with a clear verdict across store and ERP.
scenario
-
Dynamics 365 Business Central holds the true stock and prices, but WooCommerce has to be updated to match. Doing it by hand across products and variations is slow, and a careless bulk update can overwrite the wrong fields or push prices that include tax into a store that does not.
What popdock provides
--
Choose stock, price or both, and optionally a category, and it compares published WooCommerce products and variations with Dynamics 365 Business Central by SKU. Stock is rounded down and never negative, and only differences are listed. Missing, blocked and ambiguous SKUs are skipped and named, and if price gaps share one percentage it stops to ask about tax. You confirm the change list and can drop rows. Only stock and regular price are written, results are read back, and nothing is written to Business Central.
Business outcome
---
The store reflects ERP stock and prices after one reviewed update, with nothing else touched.
scenario
-
Drip scores leads by engagement, but sales works from Dynamics 365 Business Central, so a subscriber who is clearly interested may never get a call. Moving them over means checking each email against both contacts and customers in Business Central, then creating contacts by hand with the job title Business Central insists on.
What popdock provides
--
Set a minimum lead score and optionally a company, and it reads active Drip subscribers at or above that score and checks each email against Dynamics 365 Business Central contacts and customers. Only leads unknown to both are proposed, sorted by score. Business Central requires a job title, so it asks you for one per lead or one for all, and nothing is created until you confirm. Each new person contact is read back and its contact number reported, and a failed create is reported without stopping the rest.
Business outcome
---
Sales sees your hottest Drip leads as Business Central contacts, with no duplicates of existing contacts or customers.
scenario
-
Customers billed in Dynamics 365 Business Central often never make it into Drip, so they miss product news and offers. Closing the gap means exporting customers, removing blocked ones and blanks, and checking each email in Drip, while taking care never to re-add someone who unsubscribed.
What popdock provides
--
Optionally name a salesperson and a tag, and it reads Dynamics 365 Business Central customers, skipping blocked ones and those without email, and checks each address in Drip. Unsubscribed people count as present and are never re-added. Before writing, it lists the missing customers and asks you to confirm you have consent to email them. Confirmed customers are added to Drip with the tag and their country, then read back so you see each new subscriber or the error. Large result sets must be narrowed by salesperson first.
Business outcome
---
Paying customers join your Drip audience with consent confirmed, and past unsubscribes stay respected.
scenario
-
A sales rep with open opportunities in Dynamics 365 Business Central cannot see whether the contact is opening marketing email in Drip. Finding out means looking up each contact's email in Business Central and then searching Drip, deal by deal, so nobody knows which pipeline is warm and which contacts have unsubscribed.
What popdock provides
--
Optionally name a salesperson and company, and it reads open Dynamics 365 Business Central opportunities, finds each contact's email and looks it up in Drip for status, lead score and active email series. Every deal is marked Warm, Cold, Unsubscribed, Not in Drip or No email, sorted by expected closing date, with the total estimated value in each group. It is read-only, so no opportunity, subscriber or campaign is changed.
Business outcome
---
You know which open deals have an engaged contact and how much pipeline sits with unreachable people.
scenario
-
Before a customer call you want to know both their account standing in Dynamics 365 Business Central and how marketing is treating them in Drip. That means checking customers and contacts, pulling invoices and open orders, then searching Drip, and conflicts such as a blocked customer still getting promotions go unnoticed.
What popdock provides
--
Give an email address and optionally a company, and it finds the person as a Dynamics 365 Business Central customer or contact and in Drip. For a customer it pulls balance due, credit limit, recent invoices with remaining amounts and open quotes and orders. The Drip side shows status, lead score, lifetime value, tags and each email series. It flags conflicts such as an unsubscribed active customer or a balance due while still in active series. When several records match it shows them all rather than guessing, and nothing is changed.
Business outcome
---
One read-only profile joins account standing and marketing status, so conflicts surface before you speak to the customer.
scenario
-
Collections may be chasing a customer in Dynamics 365 Business Central while Drip keeps sending them cheerful promotions. Spotting the overlap means listing customers over a balance threshold and searching each one in Drip, checking both subscriber status and email series, which nobody has time to do every week.
What popdock provides
--
Set a minimum balance due and optionally a company, and it reads Dynamics 365 Business Central customers over that threshold and checks each email in Drip for status, lead score and active email series. The table is sorted by balance with blocked status and salesperson, and counts show who is still marketed to, unsubscribed, not in Drip or missing an email. Above 100 customers it works the largest balances and says how many were left out. It is read-only, so collections and marketing decide together what to change.
Business outcome
---
Collections and marketing see which overdue customers are still being emailed, without anything being paused or changed.
scenario
-
Leadership asks what a Drip campaign brought in, but the revenue lives in Dynamics 365 Business Central. Answering means exporting the campaign subscribers, matching emails to customers, and summing posted invoices since launch, and it is easy to overstate the result as revenue the campaign caused.
What popdock provides
--
Name a Drip campaign and optionally a company, and it finds the campaign, stopping to let you pick if several match, then reads up to 200 subscribers and matches them to Dynamics 365 Business Central customers by email. It totals posted invoices before tax since the campaign was created and reports the match rate, invoice count, top 10 customers and unmatched subscribers. Shared emails between customers are flagged. It states that this is invoiced revenue from people on the campaign, not proof of cause, and changes nothing.
Business outcome
---
A clear, honestly framed revenue figure for a Drip campaign audience, built from real Business Central invoices.
scenario
-
Drip shows a lifetime value for each subscriber, but finance trusts the invoices in Dynamics 365 Business Central. When the two drift, segments built on lifetime value target the wrong people. Comparing them by hand means matching emails to customers and summing every posted invoice per person.
What popdock provides
--
Set a minimum lifetime value and a tolerance, and it reads high-value Drip subscribers, matches each to a Dynamics 365 Business Central customer by email and sums their posted invoices including tax. Rows where the difference exceeds the tolerance are flagged, sorted by size, with counts of those within tolerance and those with no customer. It notes invoice currencies and flags mixed currencies rather than converting, and rereads with a higher limit if an invoice list is cut short. Nothing is updated in either system.
Business outcome
---
You find where Drip lifetime value disagrees with booked invoices, so segments rest on numbers finance recognizes.
scenario
-
An overdue tag in Drip lets marketing hold promotions for customers who owe money, but it goes stale the moment someone pays. Keeping it accurate means checking balances in Dynamics 365 Business Central, adding the tag to new overdue accounts and removing it from those who have settled, by hand, every time.
What popdock provides
--
Set the tag, a balance threshold and optionally a company, and it builds two lists: Drip subscribers whose Dynamics 365 Business Central customer is over the threshold and not yet tagged, and tagged subscribers whose balance has dropped or who no longer match a customer. You confirm both lists, one of them, or with emails excluded, and nothing changes before that. Customers not in Drip are listed, never created, Business Central is never written to, and each changed subscriber is read back.
Business outcome
---
Your Drip overdue tag tracks real Business Central balances in both directions, with every change confirmed first.
scenario
-
When sales signs up a new account in Dynamics 365 Sales, someone in finance has to create the same customer in Business Central before an order can be invoiced. Checking each account by number and name, retyping the address and credit limit, and avoiding near-duplicates is slow, so new customers are often missing when the first order arrives.
What popdock provides
--
Name a Business Central company, and optionally a state and how many to create, and it reads active Dynamics 365 Sales accounts and looks each one up in Business Central by account number, then by name. A name match only counts when the email or city also agrees, and anything doubtful is set aside as a possible duplicate rather than created. You see a table of the missing customers and nothing is created until you confirm, then each confirmed account is created once and the new customer numbers are reported.
Business outcome
---
Customers sold in Dynamics 365 Sales are ready to invoice in Business Central, without duplicates or retyped details.
scenario
-
Customers that buy through finance or are set up directly in Business Central often never reach Dynamics 365 Sales, so the sales team has no account, no owner and no reason to call them. Finding those gaps means comparing two customer lists by number and name and copying each record across by hand.
What popdock provides
--
Name a Business Central company and how many to add, and it reads Business Central customers that are not blocked, favoring those with sales, and checks each one in Dynamics 365 Sales by account number, then by name. Name-only matches that disagree on email or city are listed as possible duplicates and left alone. You review the missing customers, highest sales first, and nothing is written until you confirm. Each confirmed customer becomes a Dynamics 365 Sales account carrying the Business Central number, with a follow-up task to introduce the account owner.
Business outcome
---
Every customer that buys from you has an account and a next step in Dynamics 365 Sales, with no duplicates.
scenario
-
A rep closing a deal in Dynamics 365 Sales rarely knows the customer is over its credit limit or has invoices months overdue in Business Central. Finding out means asking finance, who look up the customer, add up open orders and overdue invoices and check for reminders, often after the order is already promised.
What popdock provides
--
Name the opportunity, and it finds it in Dynamics 365 Sales, resolves the account and matches the customer in Business Central by account number, then by name and email. It then reads overdue posted invoices and any reminders, and works out the credit headroom including the deal itself. You get a verdict of clear, caution or hold with the reasons, the credit and overdue figures, and a note when the two systems hold different credit limits. Nothing is changed in either system, and it says which match rule it used.
Business outcome
---
Reps know before closing whether finance will hold the order, so deals are not promised to customers on credit hold.
scenario
-
Quotes in Dynamics 365 Sales are built from price lists that drift away from the item prices, costs and stock in Business Central. Checking each line means opening every item in Business Central, comparing prices, working out margin and stock by hand, and it is usually skipped, so quotes go out below cost or for items that cannot ship.
What popdock provides
--
Name the quote, and it reads every product line in Dynamics 365 Sales and looks up the matching Business Central item by number. Each line shows the quoted price against the Business Central unit price, the margin against unit cost, and the stock available after open sales orders. Lines are flagged when they are below cost, priced differently, short on stock, blocked or missing from Business Central, with totals at quoted price, list price and cost. Nothing is changed in either system.
Business outcome
---
Quotes go out at a margin you meant, for items you can ship, before the customer sees them.
scenario
-
Orders won in Dynamics 365 Sales have to be keyed again into Business Central before they can ship. Finding the customer, matching each product to an item, copying quantities and prices and avoiding entering the same order twice is slow, and a missed check means duplicate or wrongly priced orders.
What popdock provides
--
Name the Dynamics 365 Sales order, and it first checks Business Central for an order already carrying that order id and stops if one exists. It matches the customer by account number, then name, stops if the customer is missing or blocked, and maps each product to a Business Central item. You see the mapped lines with both prices and any unmapped lines, and nothing is created until you confirm. The order and its lines are then created once, keeping the price that was sold, and the stored lines are read back and totaled against Dynamics 365.
Business outcome
---
Won orders reach Business Central once, at the price sold, without retyping or duplicate orders.
scenario
-
Finance chases overdue invoices in Business Central while sales keeps working new deals and orders for the same customers in Dynamics 365 Sales. Linking the two means grouping overdue invoices by customer, then searching Dynamics 365 Sales for each account and its open pipeline, which rarely happens before the next deal is signed.
What popdock provides
--
Name a Business Central company and a minimum overdue amount, and it totals overdue posted invoices by customer, then adds each customer's credit limit, balance and blocked flag. Each customer is matched to a Dynamics 365 Sales account by number, then by name, with name-only matches marked for checking. You get a list sorted by overdue total showing the open opportunities and unfulfilled orders at risk and their owners. Currencies are not converted, and nothing is changed in either system.
Business outcome
---
Sales and finance agree which deals to hold or escalate before more is sold to customers who are not paying.
scenario
-
The same customer is kept in Dynamics 365 Sales and in Business Central, and addresses, phone numbers, emails and credit limits drift apart. Finding the differences means opening both records and comparing every field by hand, and conflicting numbers between the two systems go unnoticed.
What popdock provides
--
Name a Dynamics 365 Sales account, and it finds the matching Business Central customer by account number, then name, then email, and says how it matched. Every shared field is compared, ignoring case, spacing, phone punctuation and country name versus code. You get a field-by-field table marked match, differs or missing on either side, the customer's balance due and blocked flag, and a recommendation of which system looks out of date. A number that points at a clearly different company is reported as a conflict. Nothing is changed in either system.
Business outcome
---
Customer records in sales and finance agree, and you know which side to correct for each difference.
scenario
-
When a customer asks where their order is, the rep sees it in Dynamics 365 Sales but the shipment, invoice and payment are in Business Central. Following it means finding the matching sales order, comparing lines, then hunting for the posted invoice and its balance, across two systems.
What popdock provides
--
Name the Dynamics 365 Sales order, and it finds the matching Business Central document by external document number, then by order name, then by customer, date and total. It compares each line's quantity, shipped and invoiced against Dynamics 365, then finds the posted invoice and its remaining amount. You get one stage, from not in Business Central to paid, a timeline and a line table with differences flagged. Totals that differ are shown side by side without assuming which is wrong, and nothing is changed in either system.
Business outcome
---
Anyone can answer where an order is, from quote to cash, in one step and without a Business Central login.
scenario
-
New vendors are set up in Business Central and then re-keyed into Ramp by hand. Someone has to work out which vendors are missing, retype names, emails and countries, and hope nothing is mistyped. Vendors get skipped, spelled differently or entered twice, and the gap only shows up when a bill cannot be paid.
What popdock provides
--
Name a vendor or leave it open, and it finds active Business Central vendors that are missing from Ramp and shows them to you. You choose which ones to create. It adds them to Ramp one at a time with the Business Central vendor number as the external id, then reads each back. Vendors with no email or country are listed instead of filled in, and close name matches go on a review list rather than being created. Nothing is updated or deleted.
Business outcome
---
Vendors set up in Business Central reach Ramp once, with matching ids and no invented details, so payments are not held up by re-keying.
scenario
-
Leavers keep their Ramp access because nobody compares the Ramp user list with the Business Central employee list. Checking means opening both systems, matching people by number or name, and noticing who is no longer an active employee but can still spend. Name lookalikes make it easy to match the wrong person.
What popdock provides
--
Optionally give a last name to narrow the check, and it reads Ramp users and finds each person's Business Central employee record by employee number, or by name confirmed against email. It reports active Ramp users whose employee is not active, listing their Ramp role, plus users with no employee record and email mismatches. It never matches on a surname alone, marks ambiguous people as ambiguous, and shows both systems' raw statuses. Nothing is changed, it only recommends.
Business outcome
---
Leavers with live Ramp access surface in one report, with roles and evidence, so access can be removed before it is misused.
scenario
-
Ramp GL accounts are synced to a chart of accounts that drifts from Business Central. Spend ends up coded to accounts that do not exist, are blocked, or are closed to direct posting, and the problem shows up when the sync or the posting fails. Checking means comparing two account lists line by line.
What popdock provides
--
Optionally give part of an account name, and it reads the active Ramp GL accounts and looks up each code in the Business Central chart of accounts. It reports codes that are missing, blocked, closed to direct posting or named differently, plus Ramp accounts with no code, then ranks the top fixes. A name difference is not called a mismatch when the code matches. If Ramp returns no accounts it stops, and neither system is changed.
Business outcome
---
Coding problems between Ramp and Business Central surface before they break a sync, with a ranked list of fixes.
scenario
-
AP staff tick Ramp bills off against Business Central purchase invoices one at a time, searching by vendor invoice number in the posted and unposted documents. Bills that never posted, or posted with a different amount, are usually only found at month end. An invoice number reused by another vendor can fool a quick check.
What popdock provides
--
Give a due-date range, and optionally a vendor name, and it reads the Ramp bills and looks each up in Business Central by vendor invoice number, first as a posted invoice and then as an unposted one. It confirms the vendor name before accepting a match and compares amount and currency. You get bills posted and matching, posted with a difference, unposted and missing, with Ramp sync status shown. Bills with no invoice number are listed as unmatchable and duplicate numbers as ambiguous. Nothing is changed.
Business outcome
---
Missing, unposted and mismatched bills are found in one pass before month end instead of one invoice at a time.
scenario
-
Purchase orders are raised in Ramp and in Business Central separately, and the two are compared by hand. Totals drift, orders exist on one side only, and nobody sees that Ramp spend has run ahead of what Business Central has invoiced until someone builds a spreadsheet.
What popdock provides
--
Give a start date, and optionally part of an order name, and it reads Ramp purchase orders and finds each one in Business Central by order number. It reports orders not found, orders with a different total, and orders where Ramp spend exceeds what Business Central has invoiced, with billing and receipt status alongside. Orders with no number are listed as unmatchable, and amounts are compared only in the same currency. Nothing is changed or archived in either system.
Business outcome
---
Order totals and billing progress are checked across both systems in one pass, so differences are caught while the order is still open.
scenario
-
Vendor credits are recorded in Ramp and credit memos in Business Central, and nobody checks that the two agree. Credits go missing on one side or get applied twice, and following one back means finding the bills it was applied to and the memo it should match.
What popdock provides
--
Name a vendor, and optionally a start date (default is the last 365 days), and it finds the vendor in Ramp, reads its credits and the bills they were applied to, then reads the vendor's posted credit memos in Business Central. It matches by reference number and reports credits and memos with no partner, amount differences, and whether the applied amount agrees with the remaining amount. It stops if more than one vendor matches, compares only in the same currency, and counts archived credits without listing them. Nothing is created or changed.
Business outcome
---
Lost or double-applied vendor credits are found in one comparison, with matched and unmatched items clearly separated.
scenario
-
Finance compares the Ramp vendor list with the Business Central vendor list by hand in spreadsheets. Vendors that are missing on one side, blocked in one system but live in the other, or recorded in a different country slip through until a payment fails.
What popdock provides
--
Optionally give part of a vendor name, and it reads vendors and their default contacts from Ramp and vendors from Business Central, up to 100 per side. It matches by email first, then by normalised name, and reports vendors in one system only, status conflicts and country differences. Partial name matches are listed as possible matches for a person to decide. It says when a side is cut off at 100 records, stops if either side is empty, and never creates, updates or deletes a vendor.
Business outcome
---
Vendor mismatches between Ramp and Business Central are caught in one report before a payment fails.
scenario
-
To judge one vendor, someone pulls spend from Ramp and open balances from Business Central separately, and the two views are never put side by side. A vendor blocked in Business Central can stay active in Ramp, and open amounts that disagree go unnoticed.
What popdock provides
--
Name a vendor, and it finds it in Ramp and Business Central and puts both views together: Ramp spend over 30 days, 365 days and all time, open bills and unused credits, alongside the Business Central balance, balance due and open posted invoices. It flags vendors blocked in Business Central but active in Ramp, open amounts that differ by more than 1 percent and overdue items. It stops if the name is ambiguous, shows both currencies instead of a difference when they differ, and says plainly when the vendor exists on one side only. Nothing is changed.
Business outcome
---
One vendor review shows spend, open bills, credits and balances from both systems side by side, with the risks flagged.
scenario
-
Business Central item masters are checked against the Avalara AvaTax catalogue by exporting both lists and comparing them. Items that are missing from AvaTax or carry a missing or inactive tax code are easy to overlook.
What popdock provides
--
Ask for a set of Business Central items and it looks each one up in Avalara AvaTax. It reports items missing from AvaTax and items whose tax code is missing or inactive. It checks at most 25 items at a time and says so, and blocked items are reported separately. Nothing is changed in either system.
Business outcome
---
Items with missing or inactive tax codes are found without exporting either catalogue, and nothing is changed in either system.
scenario
-
Tax teams cross-check Business Central warehouse and store locations against nexus registrations in Avalara AvaTax by hand. A gap is often found only after tax has been sourced incorrectly.
What popdock provides
--
It compares Business Central locations with Avalara AvaTax locations and with active nexus by state, then lists the states where a location exists without nexus and other gaps. In transit locations are skipped. A missing nexus is presented as an item to review, not as tax owed. Nothing is changed in either system.
Business outcome
---
Location and nexus gaps are listed for review before they cause mis-sourced tax, with nothing changed in either system.
scenario
-
Vendor details drift between Business Central and Avalara AvaTax over time. The only way to see the differences is to open both records and compare them field by field.
What popdock provides
--
Name a vendor and it reads the Business Central vendor and the matching Avalara AvaTax vendor, then reports where they differ. It stops when a match is ambiguous and separates formatting differences from real ones. Nothing is changed in either system.
Business outcome
---
Vendor records that have drifted apart are shown in one answer, with real differences separated from formatting noise.
scenario
-
Posted Business Central invoices that never reached Avalara AvaTax go uncommitted for tax. Finding them means comparing two long lists by eye.
What popdock provides
--
Give a date range and it lists posted Business Central sales invoices with no AvaTax transaction, flags probable matches filed under a different code and lists AvaTax transactions with no invoice. It warns when results are truncated and asks for a narrower range, and it reports probable matches separately instead of calling them missing. Nothing is written to either system.
Business outcome
---
Invoices that never reached AvaTax are found without comparing lists by eye, and nothing is changed in either system.
scenario
-
A credit memo is posted in Business Central, but nobody confirms the sale was reversed in Avalara AvaTax. The tax stays overstated until someone notices at filing.
What popdock provides
--
Name a posted credit memo and it checks whether AvaTax holds a matching return and the original sale. Cancelled credit memos are skipped, amounts are compared as absolute values and a missing return is reported separately from a missing sale. Nothing is changed in either system.
Business outcome
---
Credit memos with no matching AvaTax return are found before filing, with a missing return told apart from a missing sale.
scenario
-
An AR or tax analyst compares a Business Central customer with its Avalara AvaTax customer record by hand. Mismatched names, emails or addresses are missed until a tax calculation goes wrong.
What popdock provides
--
Name a customer and it reads the Business Central customer and finds the matching AvaTax customer by number, then email, then name. It reports field by field where they disagree, separates formatting differences from real mismatches and stops if either side has no record or several match. It never calls a create, update or action tool.
Business outcome
---
Customer differences between Business Central and AvaTax are found before they affect tax, with nothing changed in either system.
scenario
-
An accountant compares the tax on a posted Business Central invoice with the Avalara AvaTax transaction by hand, line by line. Differences surface only at filing.
What popdock provides
--
Name a posted sales invoice and it reads the invoice and its lines, finds the AvaTax transaction and its lines and compares tax and amounts. It checks currency before comparing, reports uncommitted AvaTax transactions as such and stops on ambiguous matches. It is a comparison, not tax advice, and nothing is changed in either system.
Business outcome
---
Invoice tax differences are found line by line before filing, with nothing changed in either system.
scenario
-
To answer what a customer owes, collections staff open two systems and add up open invoices by hand. The Chargebee and Dynamics 365 Business Central totals never quite agree, and nobody can say which invoices explain the gap.
What popdock provides
--
Give a customer email and it finds the single matching Chargebee customer, adds up their open invoices and notes the oldest due date and dunning status. It then finds the customer in Dynamics 365 Business Central and reads their balance, open invoices, credit limit, blocked flag and reminder level. You get a two column summary of Chargebee against Business Central, the difference between the two totals and the invoices that appear on only one side. It stops unless exactly one Chargebee customer matches, never subtracts across currencies and writes nothing to either system.
Business outcome
---
Collections gets one receivables view across billing and the ERP, with the gap between the two explained invoice by invoice.
scenario
-
New billing customers are re-keyed into the ERP by hand, and duplicates appear when someone searches by the wrong spelling. Before creating anything you have to read the Chargebee record, search Business Central by email and by name, then check the new customer exists.
What popdock provides
--
Give a customer email and it reads the single matching Chargebee customer and keeps their name, contact details and currency. It searches Dynamics 365 Business Central by email and then by company name, and if any customer turns up it shows it and stops. Otherwise it shows the proposed customer and waits for an explicit yes. Only then does it create the customer once, read it back to confirm it exists and report the new customer number. It never updates existing records, never writes to Chargebee and leaves credit limit and payment terms for finance.
Business outcome
---
New customers land in Business Central once, with the details you approved, and no duplicate to clean up later.
scenario
-
Credit notes raised in billing have to be mirrored as credit memos in the ledger, and nobody notices a missing one until the customer balance is wrong. Checking means listing credit notes and hunting for each posted credit memo in Business Central.
What popdock provides
--
Give a start date, and optionally one customer, and it reads the Chargebee credit notes for the period. It finds each customer in Dynamics 365 Business Central by email, then looks for the posted sales credit memo, matching first on external document number, then on the invoice it applies to, then on amount, and it says which rule matched. You get counts of matched, different, unmatched and customer missing, with every exception listed. If several credit memos could fit it lists them and refuses to choose, and it never creates credit memos.
Business outcome
---
Finance sees every credit note that never reached the ledger, with the rule used to match the rest.
scenario
-
A billing analyst checks by hand whether a Chargebee customer was set up in the ERP, and mismatched names, emails or terms are found only when an invoice fails to post. Every field has to be compared across two systems.
What popdock provides
--
Give a customer email and it finds the Chargebee customer, stopping if several match or none do. It finds the matching Dynamics 365 Business Central customer by email, trying the company name once if needed and labelling a name only match as probable. It compares name, email, phone, currency and payment terms, and shows Chargebee unbilled charges and excess payments next to the Business Central balance, balance due and blocked flag. You get a table of every field marked match, mismatch or missing and a one line verdict. It never creates or updates anything.
Business outcome
---
Billing and finance find customer record differences before an invoice fails to post, without touching either system.
scenario
-
Month end close means exporting Chargebee invoices and ticking them off against posted ERP invoices in a spreadsheet, and missing or mis-keyed invoices surface weeks later. Matching has to be done customer by customer.
What popdock provides
--
Give a start date, and optionally one customer and a maximum number of invoices, and it reads the Chargebee invoices. It finds each customer in Dynamics 365 Business Central by email and then the posted sales invoice, matching first on external document number, then on reference, and only then on total and date, and it says which rule matched. You get counts of matched, different, missing and customer missing, plus a table of every exception. Voided invoices are listed separately, several candidates are listed rather than chosen, and nothing is created.
Business outcome
---
Finance closes the month knowing exactly which Chargebee invoices are missing or different in the ERP.
scenario
-
Credit controllers cross check billing dunning lists against ERP credit holds by hand, so customers in dunning keep getting served because the ERP never heard about it. Each customer has to be looked up in both systems.
What popdock provides
--
Give a due before date, or use today, and it lists the Chargebee invoices in dunning, grouped by customer with the amount due. For each customer it reads the email, company and collection setting, then finds them in Dynamics 365 Business Central and reads their balance due, credit limit, blocked flag and highest reminder level. You get customers ranked by Chargebee amount due with a risk note: already blocked, over credit limit, no reminder raised or not in Business Central. It recommends a block but never applies one, and does not compare across currencies.
Business outcome
---
Credit controllers see which dunning customers the ERP is still treating as safe, so holds can be applied where they matter.
scenario
-
Cash application means comparing gateway payments in Chargebee against ledger receipts line by line, and unapplied or missing receipts hide until the aged debtors report is wrong. Refunds make the matching harder.
What popdock provides
--
Give a customer email and a start date and it finds the single matching Chargebee customer and reads their successful payments, treating refunds as negative amounts. It finds the customer in Dynamics 365 Business Central and reads their detailed ledger entries for payments and refunds. It pairs each payment with a ledger entry of equal amount within five days, preferring one that mentions the transaction or reference number, and uses each entry once. You get payments with no ledger entry, ledger payments with no Chargebee transaction and mismatched amounts, with totals per side. Failed and voided payments are excluded and counted, and nothing is created.
Business outcome
---
Finance sees which Chargebee payments are missing from the Business Central ledger before the aged debtors report goes wrong.
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.