ChatGPT
Claude
Google AI
Copilot
Third-party billing and Salesforce Revenue Cloud can be connected without splitting finance, if one of them owns the invoice amount. Revenue Cloud can own quote-to-cash, from the quote through to the invoice. Or the billing system can own the invoice, and Revenue Cloud stops at the quote or the order that was sold. Both arrangements work. Writing the amount into both, and hoping a reconciliation job makes them the same, does not. You get two ledgers and a close that cannot finish.
The failure is the close itself. A customer disputes a figure. The portal, which sits on the billing system, shows one amount. The order in Revenue Cloud shows another, because someone typed an adjustment into the copy and the integration pushed it back as if the two figures were peers. Finance asks which number is real. The integration team has a job that compares them and a ticket queue of differences. They do not have a sentence. The close waits on a meeting. The meeting cannot invent, in that week, an owner that should have been named before the first mapping workshop.
Pick the owner before that workshop. Write one sentence where finance can see it: when the two figures disagree, this one wins, and the other is corrected. An integration that cannot point at that sentence is not ready to build. The same sentence has to match whatever you decided for an ERP in the path. One amount, one writer, including when SAP or another ledger is also in the picture. That neighbouring decision is in Salesforce and an ERP. Two projects that each pick a winner will meet at the close, and they will disagree.
What each side is allowed to write
If Revenue Cloud owns the invoice, the billing system may receive a copy for collection, for tax submission, or for a customer portal it already runs. It does not reprice that amount, reissue it, or push an adjustment back as if the two figures were equal. Adjustments are made in Revenue Cloud, then sent out again. The copy is replaced. It is not negotiated.
If the billing system owns the invoice, Revenue Cloud may hold the quote, the products, and the order. The invoice number and the amount come back as a copy. Sales and service can read them. They do not edit them, and they do not create a second invoice on the account so the record looks complete. A second invoice is a second ledger. Usage, subscriptions, and credits follow the same rule. One calculator. The other screen displays the result.
Say this in the interface contract, in one line each: this system creates the invoice, this system may store the number, this system must not change it. If a workshop cannot fill those lines, stop the workshop. Filling them with "both, and we reconcile" is not filling them. Reconciliation is a check. It is not an owner. A workshop that cannot choose is telling you the commercial decision has not been made. Building the connector anyway freezes the indecision into a sync, and the sync will still be running at the next close.
The fields that ride along are the ones the reader needs, not the ones the source happens to have. Invoice number, amount, currency, date, status. Not the full tax engine, not every rating tier, not the internal comment a billing clerk typed. A wide copy feels safe and gives the non-owner more to edit. Every extra field is a field someone will "correct" locally. Keep the copy thin. The owner remains the place where the calculation lives.
Adjustments, credits, and the second ledger
An adjustment typed into the copy is the ordinary way the second ledger starts. The portal is where the customer is looking. A service agent, trying to help, changes the figure the customer can see. The integration is helpful, so it writes the change back. Revenue Cloud, or the billing system, now has a number it did not calculate. The next invoice run calculates the real number again. They differ. The difference looks like a defect in the connector. It is a defect in the permission to edit.
Take the edit off the screen. If a person needs to grant a credit, they do it in the owning system, or they raise a request the owning system accepts under its own rules. The request is not a write to the amount. It is a message. When the owner accepts it, the new amount is sent out and the copy is replaced. When the owner refuses it, the copy stays as it was, and the agent tells the customer the refusal. The agent does not keep a local credit "so the customer sees something today". That local credit is the second ledger, and the customer will quote it.
Usage and subscriptions are the same trap with more rows. A rating engine in the billing system and a rating engine in Revenue Cloud will both be sincere. They will not match, because they will not see the same inclusions, the same credits, or the same time window. Pick the calculator before you discuss the format of the file. A file format cannot reconcile two calculators. It can only deliver both of their answers into the close.
Who is allowed to be the calculator is a commercial choice, and it belongs to finance, not to the team that owns the connector. The connector team can say what is expensive to change later. They should not pick the owner because one API was easier to call this sprint. Easier now is how the portal became the writer. Write the owner in the place finance already looks, next to the close checklist, so a future project cannot "just integrate" a second calculator without editing that page.
Data 360 is not a second ledger
You may also send a copy of billing data to Data 360. Data Cloud was renamed Data 360 on 14 October 2025. Salesforce says the name is new and the product is unchanged, and that you may still see Data Cloud in the application and the documentation. Some Data 360 features are offered as add-on licences, and some have usage limits, though many limits can be adjusted. Plan the volume and the licence if the copy is large. The licence does not make Data 360 the owner of the invoice.
A figure in Data 360 that disagrees with the owner is a bad copy. Correct the copy. Do not open a meeting to decide which one finance should believe. You already wrote that down. A report that prefers the Data 360 figure because it is easier to query has quietly appointed a new ledger. Point the report at the owner, or label the report as a copy with a time on it. An unlabelled copy will be pasted into the close pack, and then you have three numbers.
Volume is a planning fact, not a design. If the usage limits bite, the answer is to change the licence or to send less, not to let the billing system and Revenue Cloud both keep "the" amount so Data 360 can be topped up from whichever is convenient. Convenience refills the disagreement. Send from the owner only.
A check is not a design
A daily check that the copy matches the owner is worth running. Mismatches go to a queue a person reads, and that person fixes the copy or raises a defect in the connector. The check is not permission for both systems to create the amount. Reconciliation after the fact is how two writers survive until the first audit. The queue should be small. A queue that is large every day is not a monitoring success. It is evidence the non-owner is still writing, or the copy job is dropping rows. Find which. Do not staff a permanent team to explain differences that a single writer would not create.
The person on that queue needs the sentence. When the figures disagree, the owner wins, the copy is replaced, and a local edit is a defect to remove, not a difference to split. If the person is asked to "use judgement", the sentence was never issued. Judgement is a second policy. It will differ by who is on shift, and the close will inherit the shift.
Attribute ownership, including who funds the check after the project that built it has gone, sits with the rest of the estate in integration at programme level. A check with no owner will be the first thing cut, and the two ledgers will drift until a customer or an auditor notices. Put the check on a named person's week. Keep it after go-live. Do not confuse its existence with permission to write.
Do the writing before the connector. After go-live, the disagreement shows up in a close, which is the worst week to decide who was allowed to be right. The sentence is cheap in the workshop. It is the whole design.
What finance should be able to point at
The sentence is short enough to sit on the close checklist. This system creates the invoice. This system stores a copy. This system must not change the amount. When they disagree, the named owner wins and the copy is replaced. The daily check has a named reader. A difference is a defect, not a negotiation. If a new project wants a second calculator, it edits this page first, in front of finance, before it opens a mapping workshop. A project that cannot get that edit does not get a connector.
Put the portal on the same page. If the portal is the billing system and the billing system is the copy, the portal does not become the owner because that is where customers look. Customers look where you sent them. You can send them a number you do not let them, or a service agent, rewrite. The rewrite is the second ledger. Removing the field from the screen is a product decision, and it belongs in the same week as the sentence. Leaving it for a later UX pass is how the close inherits a text box.
Read five disputed invoices the first month, with finance, against the sentence. If any dispute was caused by a write from the non-owner, the interface still allows it. Stop that write. Do not add a smarter reconciliation to explain it. The check is there to catch a broken copy. It is not there to launder a second writer into the close pack. A dispute that finance cannot trace to the owner, in one step, means the sentence is not yet how the org behaves.
