PRACTICAL RESTAURANT REFERENCE

Restaurant payout troubleshooting: trace a difference step by step

Investigate a restaurant payout difference with a practical decision path, fictional cases, a cash bridge and a clear support evidence checklist.

By Anurag · Reviewed 17 October 2026

Start with the difference you can actually explain

A restaurant owner sees a busy week in the order dashboard and a smaller number in the bank. That observation is a useful starting question, but it is not yet a calculation of missing money. The dashboard might describe orders placed during the week, while the bank credit belongs to an earlier payout cycle. The dashboard amount might include money collected for another party. Some charges may already be included in the total. A reliable investigation starts by naming the two amounts before deciding what their difference means.

This guide gives you a practical sequence for that investigation. It uses original fictional figures and a manual calculator. It does not connect to a merchant account, upload reports, contact a bank or submit a dispute. The method applies to the evidence you can obtain through an authorised account. Exact report names, entry signs, transfer schedules and responsibilities depend on the provider, market, agreement and account. Where the method asks you to verify something, that means checking the underlying record rather than filling the gap with a typical percentage found online.

The most useful result is a short explanation of each part of the gap. You might find that a transfer is still in transit, that a promotion was counted twice, or that an adjustment belongs to a previous cycle. You might also reach a genuine unexplained difference. Those outcomes deserve different next actions. A correct investigation keeps the unexplained amount visible without automatically describing it as fraud, a refundable fee or an accounting loss. The goal is an evidence trail that another person can follow from the original report to the bank movement.

Write one precise question before opening more files

Replace “the payout is wrong” with a sentence that identifies the account, period, currency, source and amount. A useful fictional example is: “For outlet Cedar One, the finalized transfer record for cycle P17 shows INR 61,400, while the two bank movements we have identified total INR 60,850.” That sentence does not assume a cause. It gives the reviewer a specific calculation to repeat. The outlet name and cycle reference in this example are invented; use the identifiers in your own private records when doing the real check.

Keep one question per investigation row. If you also want to understand why operating profit is lower, start another row with the relevant cost records. A payout can reconcile perfectly while the restaurant loses money, because ingredients, rent and staffing are not all necessarily deducted through the platform transfer. Likewise, a restaurant can have positive contribution while a bank credit is delayed. Treating these as separate questions helps the owner choose the right records and avoids answering a cash-timing question with a menu-pricing calculation.

Add a scope note next to the question. Record whether the comparison concerns one outlet or a genuinely consolidated account, one currency, and a particular set of transfer references. Do not add two currencies and label the result with whichever symbol appears first. Do not combine stores merely because they use the same restaurant brand. A combined report may have already aggregated several outlets. Before adding another export, determine whether its rows are additional records or another view of the same underlying activity.

Collect the smallest complete set of evidence

Begin with the finalized payout record, its detailed entries and the relevant bank movements. Add the order report when the payout detail refers back to orders, and add invoices or credit notes when a charge needs explanation. Keep the source files unchanged in a private reference folder. Make a separate working copy for calculations. This is a practical recordkeeping recommendation, not a claim that a particular folder structure is required by a regulator or accepted as proof by every provider.

Write down when each export was obtained and which filters were active. A report downloaded today can still describe an earlier period, an individual outlet or only one kind of transaction. The file's name is not sufficient evidence of its contents. Read the selected dates and columns inside the file, and check whether the provider describes the amount as estimated, finalized, pending or completed. If a later export differs, retain both versions and identify what changed instead of silently replacing the first number in the investigation.

A screenshot can help explain a status message, but it is not always enough for a detailed tie-out. A cropped total may omit the selected store or dates. A screenshot of one bank credit may omit another split credit. Use the original export or statement where available, and keep a readable copy of any message that is needed to understand it. Share only the minimum necessary evidence through the official private support route. Do not place customer names, bank statements, identity documents, tokens or complete merchant exports in a public community discussion.

Identify whether your starting number is sales, an estimate or a finalized payout

The starting number determines the calculation. A sales amount usually needs a bridge to the amount payable: the applicable reductions and additions must be identified, and the definition of sales must be understood. An estimated payout is a planning view that may still change. A finalized net payout is already a result after the entries included by that report. Subtracting the same entries again from a finalized net amount creates an artificial shortfall even when the bank transfer agrees with the provider's records.

DoorDash's Australian navigation guidance distinguishes estimated transactions from finalized payout details used for reconciliation. Uber's reporting guidance distinguishes Payment Details from Payment Summary. Square's payout documentation describes a payout separately from its underlying entries. Those are useful reasons to read the report definition, not a promise that every account has an identical screen or field. Keep the provider's original label alongside your own explanation. If your worksheet uses the teaching label “eligible base,” record which actual field supplied that number and what the field includes.

When you cannot explain the base, pause the numerical accusation and resolve the definition. Ask whether tax, funded discounts, refunds, tips, fees or earlier adjustments are already included. A blank answer is an unresolved question. It is not permission to enter zero. If only part of the base is understood, label the calculation provisional and list the missing explanation. A precisely written unresolved question is more useful than a fully filled worksheet whose totals depend on assumptions nobody has verified.

Align outlet, currency, transaction grain and period

A transaction grain is simply what one row represents. One file might have one row per order, another one row per financial event, and another one row per payout. An order can have several events: the original charge, a refund and a later adjustment. Adding the order total from every event row may repeat the same sale. Conversely, deleting every repeated order ID can remove legitimate refunds. Before investigating the money, write a short row description for each source and identify its stable reference fields.

Use outlet identifiers as part of the comparison key when multiple outlets are involved. An order number that is unique within one store might not be unique across a whole company. A payout reference may belong to an account rather than a store. Keep that distinction visible. Our existing settlement analyser is designed around its supported Zomato and Swiggy export workflow. It is not a general tool for arbitrary overseas reports or consolidated mixed-outlet files. Use a documented manual schedule or the appropriate workbook for a comparison outside that supported scope.

Choose a single comparison currency. The currency selector in the manual example labels your entered amounts; it does not convert them. If a real account includes foreign exchange, identify the actual conversion record, fees, date and basis separately. An unexplained exchange difference should not be hidden by changing the currency symbol. Similarly, keep order counts separate from financial-event counts. A financial report with more rows than the order report is not automatically wrong, because several events can legitimately relate to one order.

Separate the order date, eligibility cutoff, payout date and bank date

Four dates can describe the same flow of money. The customer places an order on one date. The provider includes its financial entry in a period determined by its reporting rules. A transfer is initiated on a payout date. The bank records the movement on a bank date. Sometimes these dates coincide; sometimes they do not. The investigation should preserve each relevant date rather than overwrite them all with a single convenient day or assume every dashboard uses the same time zone.

Suppose an invented restaurant's reporting day ends after midnight. An order accepted late on Sunday may appear in a Monday-based export depending on the report's definition. That example illustrates why the cutoff matters; it does not prescribe a provider's actual cutoff. Check the account's current reporting explanation and the timestamps in the records. When two files use different zones, document the conversion in a working column while retaining the original timestamp. Do not change source dates just to make a daily total agree.

Use a timing schedule when the business period and transfer period differ. List the eligible entries, their expected transfer reference and the bank movement identified so far. If the provider says a transfer is pending, do not mark it as a missing completed payment solely because the owner's preferred arrival date has passed. Follow the account-specific status and the bank's actual information. This guide does not promise a universal number of banking days or a common weekend rule across Zomato, Swiggy, DoorDash, Uber Eats or any other platform.

Build the fictional cash bridge once

Consider a fictional cycle with an eligible amount of INR 82,000 before the separately listed deductions below. For this teaching example, restaurant-funded discounts are INR 2,100, fees are INR 14,900, the entered tax on services is INR 2,235, refunds are INR 765, credits are INR 350 and withholding is INR 950. These are invented input amounts. In particular, INR 2,235 is not a recommended statutory tax calculation. The example assumes that none of these separately listed deductions has already reduced the base.

The expected amount is INR 61,400. If identified net bank movement is INR 60,850, bank minus expected is negative INR 550. Preserve that direction in the worksheet. A positive INR 550 would mean that the identified bank movement is higher than expected, which is a different question. Neither direction establishes the cause. First verify that the bank amount belongs to the same transfer, that all relevant movements have been included, and that each bridge entry appears exactly once.

Use the finalized-net comparison when the provider already supplies INR 61,400 as its net result. Compare that amount directly with INR 60,850. Do not deduct the INR 14,900 fee or any other bridge item again. If the finalized result differs from your independently built bridge, investigate that earlier difference before treating the bank as the only source of error. Keeping two comparisons separate makes the work easier to explain: source entries to provider net, then provider net to bank movement.

Check who funded a promotion and where it was recorded

A customer-facing offer does not by itself show who bore its cost. The restaurant, platform or another party may fund different parts under the actual arrangement. Find the entry that states the restaurant's financial effect. Keep the visible customer discount separate from the restaurant-funded deduction used in the bridge. If the restaurant's sales field is already net of its funded share, entering the same share as another deduction will make the expected payout too low.

For an invented mini example, an order summary starts at INR 10,000 and already reports INR 9,600 after an INR 400 restaurant-funded reduction. If you use INR 9,600 as the base, a second INR 400 deduction repeats that adjustment. If you choose the original INR 10,000 instead, the INR 400 belongs in the bridge once. Both routes can produce the same result when the definitions are consistent. The correct choice comes from the source field and documented treatment, not from which route makes the final number look closer to the bank.

Separate campaign analysis from transfer reconciliation. An advertising invoice may concern a campaign period rather than the order period you selected. A promotional credit may arrive later. An order attributed to an advertisement does not automatically mean it was an additional order caused by the advertisement. Record those questions in the campaign worksheet and use the relevant invoice or credit in the payout investigation. A single label such as “marketing” should not hide three different issues: attribution, funding responsibility and the actual settlement movement.

Trace refunds as financial events

Start with the original order reference, the refund or adjustment reference, the recorded amount and its effective date. Determine whether the refund is already included in the sales or payout number being used. Keep operational information separate: an order being marked inaccurate does not, by itself, establish a particular financial debit or who ultimately bears it. Read the actual financial record and the applicable account guidance. The tool does not decide whether a refund should have happened or whether a dispute will be accepted.

A fictional order for INR 900 can be followed by an INR 200 partial refund. The sale and refund are two related events, not two separate sales and not a duplicated order to delete automatically. If an export repeats the order's descriptive columns on both rows, summing those descriptive totals may overstate revenue. Identify which column contains the event amount and which fields are merely repeated context. This is why a stable event identifier, event type and sign convention matter alongside the order ID.

Keep later corrections visible. A refund debit can be followed by a credit, reversal or further adjustment. Match those records through their references rather than replacing the original debit with the latest amount and losing the history. If you cannot establish whether a later credit fully or partly relates to the debit, leave the link unresolved. Provider rules on refund responsibility, supporting evidence and dispute timing vary. Use the official guidance for that account and market; do not rely on a universal deadline or a third-party promise that every error charge can be recovered.

Distinguish a fee invoice from a second payment

An invoice can document a charge that has already been withheld from a payout. Seeing both the invoice and the withholding does not necessarily mean there are two expenses or two collections. Identify the invoice number, service period, charge components, total and settlement reference. Then determine whether the settlement deduction is the mechanism through which that invoice was collected. This relationship must be established from the records; similar amounts alone do not prove the match.

Imagine a fictional invoice with service value INR 14,900 and an entered service-tax amount of INR 2,235, total INR 17,135. The payout detail lists a corresponding INR 17,135 deduction. If both records concern the same charge and the deduction settles that invoice in full, subtracting another INR 17,135 because the invoice exists would repeat the collection in the bridge. The numbers here illustrate a document-to-payment link. They do not determine applicable tax rates, credit eligibility or the restaurant's accounting treatment.

Some invoices cover several transfers, or several invoices are settled through one adjustment. Build an allocation schedule when that occurs. The allocated parts should total back to the source invoice and to the settlement entries without repeating the full invoice on every row. Do the same for credit notes. A credit note can reduce an invoice balance while a separate cash credit records how that reduction was actually settled. Keep document values and cash movements in their own columns so that a document correction is not automatically counted as another bank receipt.

Look for split credits, reversals and grouped deposits

A single expected amount can arrive through more than one bank movement. In the main fictional cycle, credits of INR 40,000 and INR 21,400 total INR 61,400. Comparing the expected amount only with the first credit would show an artificial shortfall of INR 21,400. The useful work is identifying both movements as part of the same transfer, not merely finding two credits that happen to sum to the right number. Use the provider's transfer record and the bank references where available.

The opposite pattern is also possible: one bank deposit may group several documented items. A matching table can show which source records are included in the grouped movement. Avoid counting the grouped deposit and its component descriptions as separate cash receipts. If the bank statement includes a reversal, retain both the original credit and the reversal when calculating the net movement for the defined scope. A later successful credit can then be linked separately, preserving the sequence rather than erasing the failed transfer from the record.

Do not force a matching combination solely because its sum fits. A restaurant can receive other receipts, including direct customer payments, supplier refunds or owner transfers. Those are not platform payouts merely because they fill a gap. Record the evidence used for each match and leave unrelated credits outside the comparison. Where a bank reference is shortened or ambiguous, ask through the appropriate private bank or provider channel. Keep the unresolved amount visible until the reference can be connected reliably.

Preserve negative balances and unexpected overpayments

A useful check must be able to show that the calculated expected amount is negative. Consider a fictional cycle with an eligible base of INR 1,000, a fee of INR 150 and refunds of INR 1,200, with the other bridge entries confirmed as zero. The arithmetic gives negative INR 350. Turning that result into zero would hide the fact that the entered adjustments exceed the base. The next step is to read the signed provider entries and account balance, not to assume the site has proven that a particular bank debit is authorised.

The manual tool accepts signed finalized-net amounts and signed net bank movements. A bank credit is positive and a bank debit is negative under this teaching convention. Other bridge deductions are entered as positive reductions. If both the finalized net and bank movement are negative INR 350, their signed difference is zero. If your source uses a different sign convention, translate it in a documented working column and retain the original. Never apply the teaching convention blindly to a provider's raw fields.

An overpayment-looking result also deserves investigation. If expected net is INR 61,400 and the matched bank movement is INR 61,950, the positive INR 550 difference should remain visible. Check whether it belongs to another cycle, a credit or an incorrect match. Do not quietly offset it against a different unexplained shortfall simply to make the combined total zero. Offsetting can hide two separate problems and make the later explanation harder. Keep each item's reference, amount, status and evidence until the relationship is established.

Use an opening-to-closing schedule when timing crosses a month

A month-end schedule can explain amounts earned or payable in one period but received in another. For an original fictional example, opening unsettled money is INR 4,200. New payable entries during the month are INR 18,500. Identified bank transfers are INR 16,000. The closing unsettled amount is therefore INR 6,700: opening plus new payable entries minus matched transfers. That calculation describes the stated schedule. It does not by itself determine the restaurant's statutory accounts or prove that every remaining amount is collectible.

List the references that make up the INR 6,700. A total without a supporting list cannot show whether an old item was forgotten or a new item counted twice. Separate genuinely outstanding transfers from differences caused by unknown definitions or missing records. Give each unresolved item its own age based on the relevant event date and a specific next action. “Waiting” is not a sufficiently clear action when nobody knows which document is needed or who is responsible for obtaining it.

When the next month's credit arrives, match it against the existing open item instead of treating it as an entirely new earned amount. That preserves the connection between the original period and later cash. If the credit differs, identify whether the difference is explained by a subsequent adjustment or still unresolved. Use the month-end reconciliation guide for a broader closing walkthrough. The payout tool is one checking aid within that process, not a complete accounting ledger or a substitute for professional review of your actual business records.

Prepare a support question that can be answered

A good support note starts with the exact unresolved question and the smallest relevant references. State the outlet or account scope, currency, payout reference, finalized amount, identified bank movement and signed difference. Explain what you already checked, such as whether another split credit exists or an invoice deduction is already included. Keep the tone factual. An evidence-based question is easier to investigate than a broad accusation containing many unrelated screenshots and no repeatable calculation.

A fictional note might say: “For cycle P17, our finalized record shows INR 61,400. We identified net bank movement of INR 60,850 for the same reference. Our working difference is bank minus finalized payout, negative INR 550. We checked the selected outlet, period and both bank-credit entries. Please help identify any additional transfer or adjustment linked to this reference.” This is a writing example, not an official support template or a promise that the provider accepts these exact fields.

Follow the official support route available in your account and keep the response reference privately. Only include personal or financial information when it is necessary and appropriate for that channel. Do not send passwords, OTPs, account tokens or customer-level data to this website. Do not grant a stranger merchant access because they promise to recover deductions. Our diagnostic produces a sequence of checks; it does not represent the restaurant, obtain account access, file a dispute or guarantee a recovery.

Use the diagnostic and calculator for different jobs

The diagnostic asks what you are comparing, whether the scope matches, whether transfer timing has been checked and whether the evidence is complete. Its result is a suggested next checking sequence. It can point out that finalized evidence is missing or that outlet and period differences need resolving before the amount is interpreted. It does not calculate whether a fee is contractually correct and does not access a provider's internal payment system. Answer “not sure” when that is the honest state of the investigation.

The cash-bridge calculator performs arithmetic on your entered values. It assumes bridge deductions have not already reduced the base and treats entered credits as additions. The finalized-net calculator compares an already calculated payout with net bank movement. Neither calculator can inspect the source files to determine whether those assumptions are true. The most important input is therefore the owner's documented choice of scope and base, not simply a number copied into every box.

Amounts accept at most two decimal places in the displayed manual models. Use the units stated by the fields and a single currency. Blank values are rejected rather than silently becoming zero. When you change an input or currency, the old result is cleared until you calculate again. Currency selection changes the interpretation label, not the amount through foreign exchange. For more detailed working records, use the Excel workbook guide and keep the original documents separately. A local worksheet remains a calculation aid, not confirmation that an entered assumption is valid.

Close the explained part and keep the rest open

An investigation does not have to be entirely resolved before useful progress can be recorded. If INR 400 of a fictional INR 550 gap is explained by a documented adjustment, record that explanation and leave INR 150 unresolved. Keep the original INR 550 comparison, the explained component and the remaining amount in separate columns. Replacing the difference with zero because one explanation was found hides the remaining question. A reviewer should be able to see how the open amount changed.

Use clear statuses such as definition needed, source record requested, transfer pending, explanation documented and unresolved difference. These are internal working labels, not provider statuses. An item should move to explanation documented only when the relevant record and calculation support it. If a staff member received a verbal explanation, write down what was understood and ask for the appropriate reference where needed. Distinguish the restaurant's own conclusion from a written provider response.

Assign an owner and next review date for each remaining item. A date is an internal reminder, not an invented legal deadline. Track actual provider response or dispute deadlines separately using their current guidance. At the next review, ask what evidence has changed. Do not repeatedly download the same file or submit the same question just because the owner feels anxious about the balance. A focused follow-up names the previous reference and the specific information still missing, making the history understandable to the next person involved.

Make the process usable by the next shift or bookkeeper

A simple handover should identify the question, working file, original evidence, unresolved amount and next action. Keep references stable when people sort a spreadsheet or add new rows. A note attached only to “row 12” can become misleading if the table is reordered. Use a case ID and a source reference beside the note. The case ID can be an internal code that reveals no customer identity and remains unchanged while the investigation progresses.

Agree which person can prepare the calculation, which person can confirm the source interpretation and which person is authorised to contact support. These responsibilities may belong to one owner in a small restaurant or several people in a larger business. Their purpose is clarity, not the creation of an elaborate approval chain. A helper should not need another person's password to understand a worksheet. Use the provider's supported account-role arrangements if real account access is necessary.

Periodically review recurring causes. If many investigations begin with the wrong date filter, improve the export instruction. If invoices are repeatedly counted twice, improve the invoice-to-settlement map. If partial bank credits are often missed, add a step to identify every movement before calculating the gap. The learning should change the working process, not merely add another warning paragraph to an already long document. Keep the process short enough to follow while retaining the detailed explanation for situations that need it.

Three additional fictional cases to practise the method

Case one: the deduction that was already in the base

A fictional takeaway exports “net restaurant amount” of INR 19,200. Its owner subtracts an INR 800 restaurant-funded offer and INR 3,000 in fees, then compares the result with a bank credit of INR 16,200. The owner thinks the bank has paid INR 800 more than expected. Reading the report definition shows that the INR 19,200 already includes the funded offer. The corrected bridge subtracts the INR 3,000 fee once and gives INR 16,200. The apparent overpayment came from repeating the offer, not from an unexplained extra transfer.

The case is resolved only within its stated assumptions: the fee is not already netted, the records concern the same scope and there are no other entries. In a real investigation, establish those facts from the documents. The transferable lesson is to map each reduction to its source and whether it is already present in the chosen base. A familiar label such as “net” should trigger a definition check rather than a guess about what has been deducted.

Case two: a shortfall that is actually a second bank credit

A fictional café has finalized payout of INR 28,700 and initially identifies a bank credit of INR 20,000. Its first signed difference is negative INR 8,700. The reviewer checks the transfer references and finds a second credit of INR 8,700 that belongs to the same documented payout. Together the credits equal INR 28,700. The investigation records the two matching references and zero remaining difference. It does not delete the first calculation; it shows how the later evidence explained the amount that was initially open.

Now change the case: the second credit is only INR 8,200. Total identified credits become INR 28,200, leaving negative INR 500. Finding a partial explanation does not make the remaining INR 500 disappear. The next action is to locate the record that explains that balance or raise a precise support question. This small change demonstrates why a process needs an explicit remaining-difference column rather than a single checkbox that says “bank checked.”

Case three: the same order appears in several financial events

A fictional cloud kitchen exports an order row for INR 1,100, a refund event of negative INR 300 and a later correction credit of INR 100. The financial-event total is INR 900 under the stated signed convention. A descriptive column repeats the original INR 1,100 on all three rows. Adding that descriptive column would show INR 3,300, which is not the event total. Removing every repeated order ID would leave only the first row and miss both financial changes.

The correct teaching approach retains the original order and each distinct event, then calculates the relevant event amounts once. It also checks whether the later correction really relates to that refund. The case does not imply that a particular provider uses these exact column names or exports this structure. It illustrates the need to understand row grain before cleaning or summing a file. Read the data-cleaning guide for more examples of preserving that trail.

Exercises with explanations

Exercise one: decide which comparison comes first

An owner has a sales dashboard total of INR 45,000, a report described as an estimated payout of INR 33,000 and a bank credit of INR 31,500. The restaurant asks whether INR 1,500 is missing. What should happen first? Identify whether a finalized payout record exists and align its outlet, currency and eligibility period with the bank movement. Comparing the estimate directly with the bank may be useful as a provisional question, but it does not establish a finalized shortfall. The missing piece is a defined, finalized comparison basis.

An effective answer names the evidence needed rather than choosing a likely fee percentage. It also preserves the three original numbers as different measures. The owner may eventually discover that INR 31,500 is exactly the finalized amount, that a separate transfer remains pending, or that a difference needs support review. The exercise does not prescribe which outcome will occur. It tests whether the reader can avoid turning an incomplete comparison into a conclusion before the relevant record is available.

Exercise two: keep an unexplained amount visible

A finalized payout is INR 12,800. Bank movement identified so far is INR 12,100. A later document explains INR 450 of the difference through a related adjustment that was not included in the first working schedule. The original bank-minus-payout comparison is negative INR 700. After the INR 450 explanation is recorded, INR 250 remains to be explained. Do not mark the whole case complete simply because the reviewer found a plausible adjustment. Link the INR 450 record and give the INR 250 a specific next action.

The exercise assumes that the adjustment is valid for the same scope and has the direction needed to explain that part of the difference. In real work, verify both points. A credit of INR 450 with the wrong reference or opposite sign is not an explanation merely because its absolute value is convenient. Reconciliation is a matching process with a calculation trail, not a search for arbitrary numbers that bring the final cell to zero.

Exercise three: separate cash reconciliation from profitability

A fictional restaurant receives a payout that matches every finalized entry and bank movement. It then discovers that ingredient and staffing costs make the operating month unprofitable. Has payout reconciliation failed? No. The payout check answered whether the specified financial entries and cash movements agree. Profitability asks a broader question about the revenue and costs included in the operating model. A matched payout is not evidence that the menu price covers all costs, just as an unsettled cash amount does not automatically determine the month's profit.

The practical next step is to use the relevant contribution, food-cost and monthly case guides with a consistent accounting basis. Keep the already completed payout investigation as supporting work. Reopening it without new evidence will not explain rent, recipe yield or staffing decisions. A small restaurant benefits when each worksheet has one clear question and a stated boundary. The final decision can combine those worksheets, but their individual definitions should remain visible and independently understandable.

Sources, scope and your next action

The provider-specific distinctions above are supported by DoorDash's Australian Merchant Portal guidance, Uber's Payment Details explanation, Uber's UK report descriptions and Square's payout documentation. Reviewed 17 October 2026. These sources describe their own products and contexts. The fictional cases, manual sign convention and checking sequence are original teaching material, not replicas of an authenticated merchant account or promises about every market.

Choose the earliest unresolved question in your own investigation. Confirm the base, align the scope, obtain finalized evidence, calculate the bridge once, match all related bank movements and document any remaining difference. Use the payout troubleshooting assistant when you need help choosing the next check. Keep actual records privately and follow the current official support and professional advice relevant to the business. A useful final note says what was explained, which evidence supports it and exactly what remains open.