# The Deal Is Not in the Spreadsheet. The Deal Is the Workflow. ## From scattered files to one operating monitor for commodity brokerage There is a particular moment in every brokerage desk when everyone becomes an amateur detective. Someone asks: “Is that offer still fresh?” A broker says, “Yes, I think so.” Another says, “No, it was cancelled.” A third says, “It was updated in the Excel.” The boss asks, “Which Excel?” And then the room goes quiet, because everybody knows what comes next. A folder opens. Then another. A Telegram chat is searched. Someone downloads a file called `offers_final_new_latest_2.xlsx`. Another person says the real version is in email. There is also a PDF. There is a screenshot. Someone has a voice note. Someone else has the truth, apparently, but he is currently driving. This is not a system. This is an archaeological expedition with a price column. Commodity brokerage does not fail because people are lazy. It fails because the data is spread across too many places, in too many formats, with too many small manual decisions between them. And in a fast market, small manual decisions become large operational leaks. ## The spreadsheet is not the enemy Let’s be fair to Excel. Excel is one of the most successful pieces of business software ever created. It is flexible, familiar, fast enough, and capable of turning a normal person into a temporary accountant with only mild emotional damage. The problem is not Excel. The problem is when Excel becomes the operating system. A spreadsheet is useful for calculation, quick structuring and ad hoc analysis. It is not very good at being the live state of a brokerage desk. A live brokerage desk needs to know: - which offers are active; - which bids are fresh; - which matches are worth attention; - which trades are actually done; - which client owns which side of the conversation; - which basis, origin, delivery place and currency were last agreed; - which record is stale, cancelled or executed; - which version is the real version. A spreadsheet can contain that information. But if it is sitting in five files, three chats, two emails and one person’s memory, it does not matter that the information technically exists. A gold bar at the bottom of the sea is technically valuable. It is also not paying your invoices. ## The real problem is version fog In commodity brokerage, the same commercial idea often moves through several forms before it becomes anything real. A seller gives an offer. A buyer gives a bid. Someone changes the basis. Someone asks for a different delivery window. Someone counters. Someone says the quantity is flexible. Someone else asks whether the price includes VAT. A match appears, but it is not perfect. The broker works it. The boss wants to know if the team is moving. Execution wants to know whether the trade is real. By the time this journey is finished, the original data has often been retyped, copied, forwarded, renamed, reformatted and “slightly corrected” by a heroic person who should probably be doing something more useful. This creates version fog. Version fog is what happens when the team is not sure whether it is looking at the current version of a deal. It is expensive because it creates tiny delays everywhere: - brokers re-check information that should already be structured; - bosses ask for manual summaries; - matches get missed because one side was hidden in a file; - stale offers keep floating around; - the wrong basis or delivery place gets copied; - trades enter execution with missing or inconsistent terms; - reports become manual theatre. And the worst part is that everyone still looks busy. A chaotic workflow can produce a lot of activity. So can a washing machine full of cutlery. ## Integration is not an IT luxury Deal data integration sounds like something that belongs in a conference presentation, preferably with blue triangles and a person saying “synergy” too often. But in brokerage, integration is very practical. It means that offers, bids, matches and trades are not separate islands. It means the team has one operational layer where deal data can be created, updated, searched, filtered, matched, reviewed and moved forward. It means a bid is not just a row in someone’s sheet. It is a working object. It has a commodity, a basis, an origin, a destination, a price, a quantity, a broker, a client, a status, a timestamp and a context. It can be compared. It can be matched. It can be edited. It can be marked as stale. It can become a trade. It can later feed execution. That is the difference between keeping data and operating with data. ## Why this matters more in agri-commodities Agri-commodity brokerage is especially good at creating data chaos, because the real world is inconsiderate. Wheat is not just wheat. There is protein. There is origin. There is harvest year. There is certification. There is basis. There is a delivery window. There is currency. There may be VAT treatment. There is transport. There is a place that everyone calls by a slightly different name. A destination can be a port, a region, a city, a terminal, a warehouse, a plant, or a phrase with three places separated by vertical bars, because apparently one place was not enough. A company can appear under a short name, a legal name, a brand name, a Telegram name, and a spelling invented during a phone call from a moving car. This is why dictionaries and reference data matter. Not because someone has a strange hobby of organizing lists. But because matching, reporting, filtering, Telegram formatting and execution all depend on the same words meaning the same things. If one broker writes “Chornomorsk,” another writes “Chernomorsk,” and a third writes “Black Sea thing,” the market has not become more liquid. The data has become less useful. ## One monitor, one flow A proper broker monitor does not have to be complicated. In fact, it should make the day simpler. At the working level, the structure is obvious: - **Offers**: seller-side interest. - **Bids**: buyer-side interest. - **Matches**: possible commercial overlap. - **Trades**: agreed deals that should move into the next stage. Around that, the team needs filters: - commodity; - origin; - basis; - delivery place; - business unit; - currency; - transport type; - broker; - status; - date window. This sounds basic. It is basic. That is why it is so strange that many teams still operate this through files and chats. The point of a monitor is not to decorate the brokerage desk with another screen. The point is to give the team one shared operating picture. A broker should not need to ask whether an offer exists. The monitor should show it. A boss should not need to ask for a manual pipeline summary. The monitor should already know. Execution should not have to reconstruct the trade from a chain of messages. The trade should arrive with structured terms. This is not magic. It is simply refusing to run an industrial process through scattered notes. ## What changes for the broker For the broker, integration reduces friction. Instead of copying the same information into several places, the broker works inside one flow. A fresh offer can be created once and then searched, filtered, matched, updated or converted later. A bid can be compared with available offers instead of disappearing into a chat. A match can be worked as an opportunity, not rediscovered every morning like an ancient coin. The broker still communicates. Of course he does. Brokerage is not a monastery. But the working data stops being trapped inside the communication channel. That is the key. Messengers are useful for speed. The monitor is useful for state. If you mix those up, you get a market desk where everybody is typing very quickly and nobody knows what is true. ## What changes for the manager For the boss, the benefit is even bigger. A team-level monitor turns brokerage from “who shouted loudest today” into something measurable. You can see: - how many offers are active; - which bids are fresh; - where matches are forming; - which broker is working which flow; - where stale records accumulate; - which commodities are active; - which delivery places have real interest; - which trades are moving forward; - where execution starts to slow down. This does not replace judgment. It gives judgment something to stand on. Without integrated data, management becomes a daily oral tradition. The boss asks questions, brokers answer from memory, someone promises to send a summary, and by the time the summary arrives the market has already moved. With integrated data, the discussion changes. Instead of “what is happening?” the team can ask “what should we do next?” That is a much better question. ## The regulatory angle nobody enjoys, but everyone should respect Commodity and financial markets have a long tradition of pretending that recordkeeping is boring until something goes wrong. Then it becomes extremely exciting. CFTC rules for swap dealers and major swap participants require daily trading records to be identifiable and searchable by transaction and counterparty. They also require records of pre-execution communications concerning quotes, solicitations, bids, offers, instructions, trading and prices across channels including instant messaging, chat rooms, email, mobile devices and other digital media. Related cash or forward transactions are also covered in the recordkeeping framework. Not every agri-brokerage workflow is the same regulatory object as a swap dealer operation, and this article is not legal advice. But the operational lesson is still obvious: If the business depends on quotes, bids, offers, instructions, prices and execution terms, then scattering those records across uncontrolled files and chats is not a sign of flexibility. It is a future headache wearing a summer hat. ## Data is becoming the edge Large commodity players are not investing in data because they enjoy dashboards. They are doing it because better data changes the speed and quality of decisions. The Financial Times has described commodity trading’s move toward big data and AI as an “arms race,” with major traders investing in data processing and analytics to improve efficiency and decision-making. That does not mean every brokerage team needs a giant AI department and a room full of people called “quantitative workflow architects.” It means something simpler. Before you can have useful intelligence, you need useful data. Before useful data, you need structure. Before structure, you need one place where the deal actually lives. ## The monitor is not an archive This is the most important point. A broker monitor should not be a graveyard for old records. It should be a live operating layer. An archive tells you what happened. A monitor tells you what is happening. A good monitor shows the current state of the desk: fresh offers, active bids, matches worth attention, trades ready for execution, records that need updating, clients that need follow-up. It is not just storage. It is shared operational memory. That is what changes the behavior of a team. When everyone works from the same monitor, the market flow becomes visible. Not perfectly, because reality is still reality, and reality is famously annoying. But visible enough to act faster and make fewer avoidable mistakes. ## From files to flow The old model looks like this: Excel file here. Telegram message there. PDF somewhere else. Email confirmation. Manual summary. Another Excel. Boss asks for update. Broker searches chat. Execution asks for details. Someone retypes everything. Then someone notices the basis is wrong. The new model should look like this: Offer created. Bid created. Match visible. Counter worked. Trade recorded. Execution follows. Report generated. History preserved. That is not just cleaner. It is commercially better. Because the team spends less time hunting for the latest version and more time working the market. ## One practical rule If a deal is important enough to discuss, it is important enough to structure. That does not mean every conversation becomes bureaucracy. It means that the business object — the offer, bid, match or trade — should not live only in conversation. Conversation is where the market moves. The monitor is where the market becomes manageable. And that is the point. Commodity brokerage does not need another file. It needs one operating layer where offers, bids, matches and trades can move from noise into workflow. Because the deal is not in the spreadsheet. The deal is the workflow. --- ## Explore MN7R MN7R is a private commodity brokerage workflow monitor for Deals, Clients, EXE, team visibility, reference data governance and structured communication. It is built for teams that need fast brokerage work without losing the operating memory of the desk. [Explore MN7R](https://mn7r.com/) [Request pilot access](https://mn7r.com/contacts) --- ## Sources and context This article is not legal advice. It uses public regulatory and market context to explain why integrated deal data and structured records matter in commodity-related operations. - CFTC / eCFR: 17 CFR § 23.202, Daily trading records. https://www.ecfr.gov/current/title-17/chapter-I/part-23/subpart-F/section-23.202 - Financial Times: “Commodity traders bet on big data and AI.” https://www.ft.com/content/ffc4d781-8761-47e4-bb2b-83fa974252b1 - MN7R product context: public overview and monitor model. https://mn7r.com/