Which balance did that customer hold?

A customer says the credit never showed up, or says the next invoice still charged the full amount. Tonight, three proofs, in a console you administer. Name the balance that customer held: the transaction id, the amount, and the ending balance. If the amount is negative, write the minus. Do not drop it because a credit feels like it should be a positive number. Show a different transaction whose id, or whose ending balance, is not this one. Show another account's list that does not contain this transaction. If any of the three needs the person who wired billing, you have not named the balance. You have a receipt and a guess.

This is the balance on one customer. It is not the invoice. Which invoice did that charge pay? is the invoice id, the status, and the total. A balance can sit on the customer while the transaction's invoice field is null, and an invoice can exist while this ending balance was never stored. It is not the quote. Which quote did that customer accept? is a quote id, a status, and a total. A quote can be accepted while no balance transaction names that customer. It is not the intent. Which intent did that charge open? is a payment intent id, a status, and an amount. An intent can succeed while this customer's ending balance is a different integer. It is not the team a member joined, and it is not the text an audio file returned. Those are different objects, and they are not this id.

None of what follows is a rate for this product, and none of it is legal advice. The fields below are one processor's current description of a customer balance transaction and of a customer, and the two samples are not the same object. The counts below that are a 2020 paper about one bank's invoices. An amount on an example is not a census of your buyers. A model that never opened your customer cannot name the ending balance on the transaction you opened tonight. They do tell you which numbers people mix up when they try to sound precise about a credit they have not opened.

Stripe's customer balance transaction sample and Stripe's create response print the same object. The id is cbtxn_1MrU9qLkdIwHu7ixhdjxGBgI. 30 characters. amount is -500. ending_balance is -500. created is 1680216086. currency is usd, 3 characters. type is adjustment, 10 characters. customer is cus_NcjdgdwZyI9Rj7, 18 characters. credit_note is null. invoice is null. description is null. livemode is false, so the object is an example, not a live credit on your account. The create request sends amount=-500 and currency=usd. It does not send a description, and the response description is null. The version header on that request is 2026-10-28.endive. 17 characters. A version string is not a transaction id. The prerequisite on the same page is a customer named Jenny Rosen, email jennyrosen@example.com. The name is 11 characters. The email is 22 characters. The response does not print Jenny Rosen. It prints a customer id. Do not paste the name onto the id because the page told you to create a customer first (Stripe, Create a customer balance transaction).

The signs are the part people rewrite, and the page does not give you permission to rewrite them. On the transaction, a negative amount is a credit for the customer's balance, and a positive amount is a debit. ending_balance follows the same direction: a negative value decreases the amount due on the next invoice, and a positive value increases it. The sample stores -500 in both fields. ending_balance minus amount is -500 minus -500, which is 0. The page does not print that 0. It is the starting balance you can infer for this one sample, and it is not a field. The customer object uses the same direction for its own balance field: negative means the customer has credit to apply to the next invoice, and positive means an amount owed is added to the next invoice. A different field on that same customer page, invoice_credit_balance, states the opposite: positive in a currency means credit, and negative means an amount owed. Negative on balance is not positive on invoice_credit_balance. Copying the sign from the wrong field is how a credit becomes a debt in the sentence you send the founder (Stripe, The Customer Balance Transaction object, and The Customer object).

The customer sample is a second object, and it is not this transaction. Its id is cus_NffrFeUfNV2Hib. Also 18 characters, and not cus_NcjdgdwZyI9Rj7. balance is 0. 0 matches the starting figure you can infer for the transaction sample, and it is still a different customer. created is 1680893993. The transaction's created is 1680216086. The difference is 677907 seconds. 7 times 86400 is 604800. The remainder is 73107 seconds, which is 20 hours, 18 minutes, and 27 seconds. The gap is 7 days, 20 hours, 18 minutes, and 27 seconds. It is not zero, and it is not a reason to treat the two samples as one history. name is Jenny Rosen, the same 11 characters as the create prerequisite. email is the same 22-character address. invoice_prefix is 0759376C, 8 characters. next_invoice_sequence is 1. currency is null. A null currency on the customer is not usd on the transaction. livemode is false on both. False on one object is not a proof about the other. The name maximums on the customer page are 150 characters for business_name and 150 for individual_name. 11 is not 150. The transaction's description maximum is 350 characters. The sample description is null. Null is not 350, and 350 is not 150.

The type list on the transaction page does not agree with itself. The introductory sentence names adjustment, applied_to_invoice, credit_note, initial, invoice_overpaid, invoice_too_large, invoice_too_small, unspent_receiver_credit, unapplied_from_invoice, checkout_session_subscription_payment, and checkout_session_subscription_payment_canceled. Eleven names. The enum block then adds migration. Twelve names. migration is not in the sentence. The sample's type is adjustment, which is in both lists. credit_note is a type name, and the sample's credit_note field is null. A type you did not store is not a field you may fill. invoice is also null, so this sample is not applied_to_invoice and it is not invoice_overpaid. tax_exempt on the customer sample is none. The customer page's tax_exempt values are exempt, none, and reverse. Three names. none is not adjustment. Three tax names are not twelve transaction types, and twelve types are not amount -500.

The study people reach for when they want a collections number did not open this console. Ana Paula Appel, Gabriel Louzada Malfatti, Renato Luiz de Freitas Cunha, Bruno Lima, and Rogerio de Paula, at IBM Research, predict whether invoices will be paid late. The abstract says the prototype reached up to 81% accuracy, and that a simulation saves up to about 1.75 million dollars a month. The dataset sentence says 91,562 invoices and 2,229 customers, from six Latin American countries plus the United States. Table 1 then prints seven rows: United States 26,506 invoices and 4,276 customers, Argentina 220 and 27, Brazil 17,510 and 785, Chile 11,634 and 324, Colombia 16,302 and 514, Ecuador 6 and 1, Mexico 19,484 and 578. The invoice column adds to 91,662. 91,662 is not 91,562. The difference is 100, which the page does not print. The customer column adds to 6,505. 6,505 is not 2,229. 6,505 minus 4,276 is 2,229. The United States customer cell, removed, leaves the number the prose printed for the whole dataset. The page does not say it excluded that cell (Appel, Malfatti, Cunha, Lima, and de Paula, Predicting Account Receivables with Machine Learning).

The split does not land on the percentage the caption names. Table 2 prints 71,545 training invoices and 19,630 test invoices. The sum is 91,175. 91,175 is not 91,562, and it is not 91,662. The gaps are 387 and 487. The page does not print either gap. The caption says they use 70% of the data to train. 70% of 91,562 is 64,093.4, which is not a whole invoice and is not 71,545. 71,545 divided by 91,562 is 0.781, which is 78.1%, not 70%. The prose says training runs from November 2018 to April 2019, and the test from May 2019 to November 2019. The table prints 2018-11 through 2019-06 for train, and 2019-07 through 2019-11 for test. April is not June. May is not July. Train late is 61.17% and on time is 38.83%. Those add to 100. Test late is 54.51% and on time is 45.49%. Those also add to 100. The caption says the classes are balanced and the baseline is close to 61%. 61.17 is not 54.51, and 54.51 is not the same distribution as 45.49. A later sentence says the figure's baseline is 54.51%. Two baselines, two samples. Table 3 prints a general accuracy of 80.71 and a North America cell of 82.02. The prose rounds that cell to 82%. 82 is not 82.02, and 81 in the abstract is not 80.71. A figure caption says the last two months reached up to 85%. 85 is not 81. Their worked example multiplies a probability of 0.2506 by 1,000,000, and a probability of 0.9358 by 300,000. 0.2506 times 1,000,000 is 250,600. 0.9358 times 300,000 is 280,740. The page does not print 250,600 or 280,740. Neither product is ending_balance -500.

Do the three proofs on one real customer, in the console that actually holds the balance. First, the binding. Copy the transaction id, the customer id, the amount, the ending balance, the currency, and the type. If amount is -500 on a sample and your row is a different integer, write your integer. Do not paste -500 because the sample is tidy. If invoice is null, write null. If description is null, write null. Do not invent a sentence to fill 350 characters. Write which sign convention the screen is using, because balance and invoice_credit_balance point opposite ways. Second, the other transaction. A different id, or a different ending balance, is not this one. A chart of 91,562 other invoices is not that second transaction. If you cannot show a transaction that is not this one, you have a counter, not a record. Third, the other account. A list that belongs to someone else does not contain this id. If the only list is a single shared table and you cannot say whose customer it is, write that. A tenant you cannot name is the finding.

Three moves feel like the proof and are a second problem. Flipping the sign because a credit ought to look positive, and then describing the stored minus as a display bug. The page you were just reading uses minus for a credit on the balance field and plus for a credit on invoice_credit_balance. Both are written down. Quoting 81% because it looks precise, while the customer you were asked about is one row, and the study that printed 81% had already failed to make its own invoice total match its own table. Asking a model which type it was. The model will pick a plausible name from the twelve. It will not open the transaction. An invoice you have not kept, while the customer is arguing about a bill, is which invoice did that charge pay?. Opening that screen does not name the ending balance.

The path is ordinary when an operator can open one merchant's balance without opening the next merchant's balance as the way to prove it. PayOrch is a payment orchestration dashboard: wallets, providers, merchants, platform fees, and fraud controls in one view. The shape that matters here is one merchant you can point at, in an account you administer, distinct from the next merchant. That case is not a balance ledger. Nothing in that sentence is a headcount, a duration, or a result figure. If the only control on the screen changes every merchant's balance together, you do not have this proof. You have a totals page.

There is a version of this afternoon where hiring the path is the wrong purchase. Nothing is for sale, because the product does not take money yet. You have no product. You are still choosing who will build, and the document in front of you is a term sheet. The criteria for that choice sit on the page written for a top SaaS development company. That page is criteria. It does not rank anyone, including us. The only fact in the room is a paper about someone else's invoices. 81% is not your balance, and 91,562 is not your balance, and -500 on a sample is not your balance. A customer has already seen another customer's payment. Naming an id does not close a leak. Or you wanted a lawyer to say whether a credit is a contract. Hire the lawyer.

When the customer is real and the console cannot name the balance, the missing object is specific. An admin action, in an account you administer, that shows one transaction id, one amount, and one ending balance, shows a different transaction that is not that one, and shows another account's list without it. A startup software development company that expects this will have put that action next to the rest of the billing screen, before a stranger's complaint is the way you discover the vendor owns the credit. One that needs a call in order for you to see which balance is stored is telling you who holds the number. If the first slice is a fixed capability, an AI integration sprint is the shape where the acceptance sentence can include the three proofs. If you do not yet know which system stores the customer, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that a paper's accuracy applies, and they are not -500.

The team a member joined, and the text an audio file returned, are different objects: which team did that member join? and which text did that audio return?. Do not record either on this page. A team slug is not a transaction id. A duration is not an ending balance.

Before you tell them the credit was applied, do the three proofs and write the amount, sign included. Name the transaction, the amount, and the ending balance, or write that the customer has no balance transaction. Show a different transaction that is not that one. Show another account's list that does not hold it. Do not flip a minus into a plus because another field on the customer uses the other sign, and do not ask a model which of the twelve types it was. A paper can tell you what it counted on a bank's invoices, including the 91,562 that is not the sum of its own table. The binding is the balance you can defend.